Forums » Suggestions
Password length
See https://www.xkcd.com/936/
The maximum password length is pretty short. I can think of a lot of possible reasons for this and all of them are very bad. Hashes should be constant length anyway, so why limit it? I should be able to have a paragraph-length password if I feel like it.
The maximum password length is pretty short. I can think of a lot of possible reasons for this and all of them are very bad. Hashes should be constant length anyway, so why limit it? I should be able to have a paragraph-length password if I feel like it.
See also this thread:
http://www.vendetta-online.com/x/msgboard/2/25300
http://www.vendetta-online.com/x/msgboard/2/25300
I should pay more attention and/or search the forum.
That said, giving the devs a poke about this won't hurt. I'm concerned the passwords are being stored in plain text, and that's Bad.
That said, giving the devs a poke about this won't hurt. I'm concerned the passwords are being stored in plain text, and that's Bad.
There's no down-side to this and it clearly should be implemented.
+ umpty million coconuts
Passwords are not stored in plain text. But regardless, the length is too short. The challenge in upgrading is that we have to augment our server-side to process both "legacy" hashes along with "updated" hashes, and also have a road-map for forcing a client-side hashing-cost increase to reduce the chances of brute forcing down the road. We have a plan, we just haven't had/allocated the development resources yet.
We have a plan, we just haven't had/allocated the development resources yet.
I don't know why you don't just make that your signature for all forum posts.
Ah, yes, because the forums lack that functionality.
I don't know why you don't just make that your signature for all forum posts.
Ah, yes, because the forums lack that functionality.
Making the client hash won't really stop a brute force attack. A newer GPU can put out 600 million sha256 hashes per second. If you're using an older/faster hashing algorithm, it's in the billions.
Augmenting the server side code is pretty simple. Just switch to a newer hashing algorithm. Check the lengths of the hashes when someone attempts to login, if it's the older hash, you know to only hash the first 8 chars, if it's the newer hash, hash all of the chars. Gets more complicated if you really are doing things like client side hashing, though.
Augmenting the server side code is pretty simple. Just switch to a newer hashing algorithm. Check the lengths of the hashes when someone attempts to login, if it's the older hash, you know to only hash the first 8 chars, if it's the newer hash, hash all of the chars. Gets more complicated if you really are doing things like client side hashing, though.
Hashes can be made to scale in cost, and the cost can be increased over time. As long as the path through the hash is sufficiently torturous and non parallelizable, it can make any brute force attempt much more difficult (I am definitely not talking about SHA, which was designed for the exact opposite of this use case). Scalable cost hashing has been pretty widely written about for over a decade:
http://static.usenix.org/events/usenix99/provos/provos_html/node1.html
Our own system actually uses something similar, from about the same time. Anyway, we are aware that we can compare hashes on the server side. And yes, we do client hashing and prevent replay attacks. Regardless, when we fix this, we would prefer to make it fairly future-proofed so that we can invisibly dial it up again later without a lot of migration issues.
http://static.usenix.org/events/usenix99/provos/provos_html/node1.html
Our own system actually uses something similar, from about the same time. Anyway, we are aware that we can compare hashes on the server side. And yes, we do client hashing and prevent replay attacks. Regardless, when we fix this, we would prefer to make it fairly future-proofed so that we can invisibly dial it up again later without a lot of migration issues.