tags:

views:

68

answers:

1

Hi there,

I've been checking up on who's been signing up for one of my websites by using the brute-force SELECT * FROM tblUsers;

I hash user passwords, so they don't render as cleartext, and I noticed a strange artifact upon the display of one of them. It's difficult to explain in words, so here's the text of a recent session:

mysql> select password from tblUsers;
+------------------+
| password         |
+------------------+
| KÐÊ2®\Û‹:ã5«ƒñ_ | 
| ú¾ôn" ™µ'gxõ | 
| Ú‘¤êB3ãóÒq+« | 
+------------------+
3 _-+_ i+ _e+ (0.00 _ec)

+y_-+> 
[1]+  S+---ed                 +y_-+ -+ |b++ -- -b  (+d: ~)
(+d +-+: /+a_/+++/h+++)
[_--+@_15308575 h+++]# ech- "HUNTER2"    
HUNTER2
[_--+@_15308575 h+++]# ech- "h+++e_2"
h+++e_2
[_--+@_15308575 h+++]# ech- "abcdefghi+++++---__++++|yz"
abcdefghi+++++---__++++|yz

The paste content is a little strange; in reality, all those [+\-_a-eh-z] are rendering as █. f is rendering in-client as ±, and g is rendering in-client as '.

I'm using SecureCRT to SSH into a 1&1 VPS account (running CentOS). Is there some magic that's causing this display error? Is it in the client, or in the OS? The problem disappears when I close the session and login again.

+1  A: 

I would guess that one or more characters in the hashed passwords are being interpreted as special commands which change the terminal's encoding. Try cat'ing a binary file and you're likely to have the same thing happen.

Michael Myers
I'm an encoding n00b. I know characters have the capacity to reverse/advance the cursor, but I didn't know that they could change the encoding scheme. Cool.
kyle
On further research, I think it's more like "special commands", not "special characters". I guess my phrasing was a bit misleading.
Michael Myers
If anyone can confirm this, I'd love to hear it; I am also a bit of a noob in such matters.
Michael Myers
type "reset" to reset your terminal.
lothar
`stty sane` does pretty much the same thing as `reset`, and I find it easier to remember. (Maybe I'm odd.)
ephemient