71–80 of 96 posts
Friend of mine actually built one off SHA1 and it's all open at https://github.com/simontabor/pw/ or www.pwapp.io. It's 40 chars so much much better than pwdhash (but that's the original I guess).
Earlier quoted context omitted.
It doesn't guarantee it, but it does imply it pretty heavily. The alternative is that they're smart enough to come up with a clever scheme like hashing your password in both its raw form and when converted to 0-9, but not smart enough to realize how converting your password to 0-9 makes it vastly less secure.
No, it's easy for them to convert your password to 0-9 when you enter it on a regular keyboard, before hashing it. It does make it vastly less secure, yes, but it doesn't imply plaintext storage.
Earlier quoted context omitted.
Even if none of the sites are compromised; even if your device is not stolen or lost; even if the sites don't use password expiration it doesn't work very well because some sites are just plain stupid with their password restrictions. Some of the things you'll face: • Passwords that prevent double characters within the password: not ideal when using a scheme. • Passwords with a minimum/maximum length: I've seen sites…
Maximum length tops my list of favorite restriction, because it strongly suggests that they're keeping my password in the clear somewhere - or they used to, and just never got around to changing it. The concept of illegal characters is tied for second. If you're handling it right, there should be no such thing - yet so many sites continue to set arbitrary limitations for reasons that aren't clear even to them. Kind o…
Earlier quoted context omitted.
No, it's easy for them to convert your password to 0-9 when you enter it on a regular keyboard, before hashing it. It does make it vastly less secure, yes, but it doesn't imply plaintext storage.
Isn't that what I said in my second paragraph? As I said, for that to happen, you need people smart enough to come up with that scheme but not smart enough to realize how insecure it is. Possible but unlikely. "Imply" does not require a complete guarantee.
Earlier quoted context omitted.
No, it's easy for them to convert your password to 0-9 when you enter it on a regular keyboard, before hashing it. It does make it vastly less secure, yes, but it doesn't imply plaintext storage.
Isn't that what I said in my second paragraph? As I said, for that to happen, you need people smart enough to come up with that scheme but not smart enough to realize how insecure it is. Possible but unlikely. "Imply" does not require a complete guarantee.
1. Your password is required online where the full password must be entered and the numerically reduced password is not accepted. This results in no loss of difficulty in the password.
2. Your password is required over the phone where the password is reduced to a T9 password. Despite the fact that the solution space has been cut down significantly (by 33%^n), the password cannot be broken any quicker because the bottleneck for this case is not computational power but rather the phone system. You can brute force all of the passwords in X seconds, but this is irrelevant because you can't try more than 1 password per call and you can't call more than Y times per second.
Earlier quoted context omitted.
Maximum length tops my list of favorite restriction, because it strongly suggests that they're keeping my password in the clear somewhere - or they used to, and just never got around to changing it. The concept of illegal characters is tied for second. If you're handling it right, there should be no such thing - yet so many sites continue to set arbitrary limitations for reasons that aren't clear even to them. Kind o…
I totally get what you mean, but setting an upper limit on fields is generally a good idea. Setting the limit too low sucks, but you don't really want to accept, e.g. 1MB passwords.
Earlier quoted context omitted.
Isn't that what I said in my second paragraph? As I said, for that to happen, you need people smart enough to come up with that scheme but not smart enough to realize how insecure it is. Possible but unlikely. "Imply" does not require a complete guarantee.
Does it actually make it less secure though? Consider the situations where each password is used: 1. Your password is required online where the full password must be entered and the numerically reduced password is not accepted. This results in no loss of difficulty in the password. 2. Your password is required over the phone where the password is reduced to a T9 password. Despite the fact that the solution space has…
In the universe of banking this is pretty small potatoes, though. My bank uses a case insensitive comparison for passwords (!), limits them to 8 characters (!!), and silently truncates anything over the limit (!!!!!!!!!!!!!!!!!!!!!!!!!!).
They say they're fixing it. But it sure is taking a long time.
Earlier quoted context omitted.
I totally get what you mean, but setting an upper limit on fields is generally a good idea. Setting the limit too low sucks, but you don't really want to accept, e.g. 1MB passwords.
Why not, since you're only storing a fixed-length hash of the password?
Also, chances are users will not type their 10MB password into an input field, but try and paste it in. Again, the browser may silently discard a few MB of that string, or beep while you have your sound muted.
That's no reason to set max length at something small, but setting it to 1024 or so shouldn't limit anybody as long as it allows for more entropy in the plaintext password than will be in the hash you store.