Reply to post: Storing passwords in plain text?

For Foxit's sake: PDF editor biz breached, users' passwords among stolen data

Bill Gray

Storing passwords in plain text?

Whenever I see a 20-character upper limit, I assume passwords are stored in plain text. I could see an upper limit of, say, 500 characters to avoid DoS attacks or efforts to overflow buffers. But those smaller limits look suspiciously as if somebody wanted the unhashed password to fit into their database.

Am I wrong? Is there actually a good reason to insist on a lowish upper limit?

For that matter, I make a similar assumption when I'm told my password can't contain spaces (or commas). That suggests to me that their database would interpret my password as two or more fields. A password should be able to hold any Unicode text; after all, once hashed, it's a string of hex digits anyway.

My preference would be that my password be salted and hashed _in the browser_. This doesn't remove the need to use https or for salting/hashing to occur at the server end, but it does mean that I have good reason to think that the site I'm communicating with never sees my unhashed password and cannot, no matter how badly the security is botched, leak my unhashed password. (Which provides them with a degree of security as well, and an excellent defense if accused of leaking passwords : "It wasn't us what done it; we couldn't have done it had we wanted to.")

It also, of course, means that if I wanted a gigabyte-long password, it'd be fine. It'll just get salted and hashed and the same number of bytes get sent to the server.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2021