81–90 of 128 posts
Though to be fair, when's the last time you heard about a bank's password database getting stolen?
My bank limits my password to 8. When I questioned while creating my account, they asked me to visit the login page - in the login page you are asked for the answer of the security question and also presented with 8 input boxes - one for each of of the password characters - but having to enter only randomly selected few from the password ( for preventing key loggers from getting password, of course ). This seemed lik…
Wait. Doesn't that imply your bank is storing your password in plaintext, or at best salted and hashed each individual character of your password? (Which is still horrible, because it now takes O(n) instead of O(n^8) to crack stolen hashes)
Earlier quoted context omitted.
No; this is effectively the same as doing no hashing at all. If your database gets stolen, people can replay the "hashed" passwords from it to the server, without having to hash them themselves.
I didn't mean to imply that you'd just store the hash the client comes up with. That's idiotic, of course. Not everyone uses SSL, even though they should, and it's not always secure, and even with the use of SSL, it seems that there would be a potential length attack that could be employed to effectively guess a user's password length. So in all cases, IMO, it makes more sense to be receiving a fixed-length thing tha…
Your problem: clientHash is "password-like" and Eve can use it to log in.
One solution: use the HTTPS auth methods. Unfortunately, this is not the standard in the industry because the GUI is ugly.
The reason why this is an even bigger problem than you might think: what does the login method do? It probably sets a "remember me!" cookie, which is also "password-like" for just about every purpose. Eve sniffs the cookie and can use it to compromise the account in the future.
Also the 'remember me' cookie is probably stored in the clear in the database. So much for that, eh?
What you really want is a system based on digital signatures: whenever I make a request I digitally sign it. But the core problem is that I don't want to type in my password for every damn request, so this is being cached between requests and between page views. Depending on how it's cached, there are vulnerabiities -- especially if you just have your browser automatically fill in the password blanks, but also if you carry these "password-like" login cookies. A system of delegation and revocation can be done, but you come dangerously close to reinventing a public key infrastructure if you go too far down this road.
HTTPS auth methods can help out quite a bit, but can be hard to set up with a custom backend and hard to test against that sort of "downgrade attack" I mentioned in my first paragraph. The best of these ideas is to give your users client certificates and thus be safe forever, but nobody has found it useful enough to actually do this.
The only real alternative has been to remind the customers to always look for the s in the "https:// in the location bar. This is stupid and now there are some proposals for browsers to ship with lists which are "Expected to be secure", to avoid it, but yeah, we never really outgrew it.
Funny that the experiment was mentioned many times in different occasions, and it's not clear if it was ever conducted. Still Bears around the Internet believed it and just kept repeating it in every opportunity ;)
The hash output of bcrypt stops changing after 72 characters but almost all bcrypt documentation mentions a 55 character limit. I'm not quite sure what that is about, can anyone clarify?
For how much people like to repeat the "Use bcrypt!" mantra I'm amazed no one has mentioned the password length limit of bcrypt. The hash output of bcrypt stops changing after 72 characters but almost all bcrypt documentation mentions a 55 character limit. I'm not quite sure what that is about, can anyone clarify?
check string length
if longer than 55, remove first 55 or less characters up to end of string, store in array
repeat until string is empty
encrypt each item in the array, append them all on to each other as such
EncryptedText[0] . EncryptedText[1]... etc
Seems like a simple way to handle this. You could impose your own restrictions to stop a server DDoS by encryption requests on long strings, but to be honest if you're allowing a 100,000 character password, you're doing it all wrong.
Earlier quoted context omitted.
While this is true, hashes use a set number of characters. For example, SHA-256 hashes can be stored in 32-character hex strings. In that sense, there's no point in allowing for a variable length field for password hashes.
It's not only dealing with password length. You could DoS the server by tying up all threads in processing the upload. Uploading 4GB isn't instantaneous.
Protecting against a DoS attack this way is done in the webserver, which doesn't care about individual fields. Sure this means there's an implicit password length limit, but not in any application-level sense.
It's amazing how all the comments so far have entirely missed that it's the top answer that was really submitted, not the question.
I think it may be a problem with the link itself. In the past I've seen SO links that auto scroll to the answer of interest, however this one just loaded to the top of the page.
Earlier quoted context omitted.
Just use ROT13 - same space requirements as in plaintext (I really, really hope people realize that is a joke. Otherwise this might be the worst piece of advice I have ever given on the internet)
Yeah- you need at least rot26 or else it's just too easy to crack with today's technology. But everybody ought to know that. (Hey! It's April 1st somewhere...um, or will be in a few hours)
For how much people like to repeat the "Use bcrypt!" mantra I'm amazed no one has mentioned the password length limit of bcrypt. The hash output of bcrypt stops changing after 72 characters but almost all bcrypt documentation mentions a 55 character limit. I'm not quite sure what that is about, can anyone clarify?