Comment by femto113 | Hacker News Reader

Comment by femto113 | Hacker News Reader

Parent Full thread

This attitude ignores the fact that risk comes in multiple forms. While lowercasing the passwords increases the guess-ability of the password when attempting to log in to this site it actually reduces the value of the password in a breach of this sort, since it may not be usable verbatim on other sites even if the user typed it the same way. As this sort of breach is now quite common I think many "best practices" for password security that date back to the design of unix logins are arguably no longer best. For example if we just used CRC24 to hash passwords it would be nearly impossible to recover them from the hashes, but at a practical level would be comparably secure on the front end: it would take 1000s of guesses to find a working collision, which is easily preventable at the front gate by locking the account after a small number of bad guesses; but it would be far more secure on the backend, since any CRC24 code could derive from millions of possibilities.

Wouldn't the leakage be catastrophically worse if storing CRC24 became commonplace?

If they leak, it becomes trivial to find working password synonyms to stick into the other sites you say benefit from discarding information.

Wouldn't each company salting on their front end prevent this? If you find a password synonym that works for a single company, it probably isn't the real password, so it would give you no information on a synonym for another company (unless it is the real password, in which case you can just use it directly, no need to look for another synonym).

You seem to be describing a non-standard way of salting hashes, and in the case of modifying the case, an extremely poor way of doing it. Please don't do that.

Not changing the salting. Changing the hashing algorithm.

This is intended as a thought experiment, not a concrete design for how to properly store passwords. In fact CRC24 doesn't really burn as much information as I assumed, e.g. on the top 100,000 passwords it only generates about 300 collisions (so over 99% still generate unique hashes). If one was really going to go in this direction a specialized hash that is deliberately collision prone across password-like strings is probably needed.

by that token I'd imagine ALLCAPSing would overlap many fewer passwords that have been reused for other sites.

If you know the password in allcaps, then you know it in lowercase, so why would that matter?

Assuming other sites DON'T do this it helps the security of other sites. But it hurts the security of your site.

Overall, yeah, it's not a good thing to do!

> While lowercasing the passwords increases the guess-ability of the password when attempting to log in to this site it actually reduces the value of the password in a breach of this sort

But why don't they use the proven common-sense strategy of not storing the passwords at all, but store the hashes instead? They can validate by converting user-input to a hash and then there is no harm even if the user auth table is stolen.

Read that again, slower.

> "the hashed passwords seem to have been changed to all lowercase before storage"

According to the article they were indeed hashes, but they were converted to lowercase _before_ hashing.

This effectively makes your password case insensitive and probably reduces the % of support tickets (some people might not just click a reset password link and will insist they were typing it right, so they will open a ticket - all because they forgot capslock). It reduces operating costs at the expense of lower security and somebody must have considered it to be worth it.

Reply on news.ycombinator.com