6 ms·
> replace all passwords with a set value They're storing passwords directly and not hashes? Wish I could ask you which company so I could avoid them...
by timf 18y ago
> replace all passwords with a set value
They're storing passwords directly and not hashes? Wish I could ask you which company so I could avoid them...
- timf 18y agoDownvote all you want but I would seriously like to know. http://www.matasano.com/log/958/enough-with-the-rainbow-tables-what-you-need-to-know-about-secure-password-schemes/ http://www.matasano.com/log/958/enough-with-the-rainbow-tabl...
- inerte 18y agoWho said they're storing passwords in plain text? They could be paranoid enough to remove hashed passwords. If you know what makes the hash you can reproduce. If it's a database with financial information, I can see crackers devoting time to do this, making their rainbow tables and botnets or whatever to guess the passwords.
- sho 18y agoI don't understand this obsession about only storing hashes, as if that's the primary critical issue with site security. There are plenty of reasons to store the plaintext, and in a well secured database I really don't think it is much of an issue. Or as I heard someone say once, "If you can break into my database, and show me how, I will quite literally give you a million dollars". Off the top of my head, here's a couple of very good reasons to store plaintext: - password recoverability: if the user knows they can recover the password, they're more likely to use a more complex one - flexibility with authentication: to use something like HTTP Digest Auth, you need the plaintext to be able to hash it with a one-time nonce And like many will no doubt point out, hashing it isn't all THAT secure anyway. If it's not a very strong hash, or there's enough information to reset it somehow, they can get what they want anyway. Not to mention that if your database has been cracked they probably have everything they want anyway - why even bother logging in? I just don't get it. Sure, defence in depth is the best strategy and everyone should practise it whereever possible. But whether the password is stored hashed or not is not the lynchpin security issue many make it out to be, IMO.
- timf 18y ago"obsession about only storing hashes, as if that's the primary critical issue with site security" Can you point me to something I said that implies this is an obsession or that this is what I think the primary critical issue is with site security? " password recoverability: if the user knows they can recover the password, they're more likely to use a more complex one" Why would I as a user care at all if I could retrieve the actual value of a complex password -- and why would knowing I could recover it make me then choose a more complex one? (The user should be given an option of resetting the password via a link sent by email. Sending passwords themselves over email is a great way to have it revealed for someone else to use later.) "to use something like HTTP Digest Auth" Good thing no one needs this mediocre authentication method if SSL is available. The majority of people use the same passwords at different sites. So even if someone's cracked your database, it's still a good idea. Storing passwords in plaintext is a non-neighborly thing to do.
- sho 18y ago"Can you point me to something I said that implies this is an obsession or that this is what I think the primary critical issue is with site security?" You asked for the financial institution's name so you could avoid them, based solely on the password storage issue. That counts as obsession to me. Oh and I forgot to write it before, but financial institutions often need to store in plaintext anyway, for telephone authentication. "Why would I as a user care at all if I could retrieve the actual value of a complex password -- and why would knowing I could recover it make me then choose a more complex one?" If people know they have to remember it, they tend to choose simpler passwords, or they write it down. If you tell users to set a hard password, and they can recover it later if necessary, they would hopefully tend to use better ones. I can't really back that up with a study, though, so it could just be my experience. "The user should be given an option of resetting the password via a link sent by email. Sending passwords themselves over the email is a great way to have it revealed for someone else to use later." This is veering off topic, but you either trust the email or you don't. What, pray tell, is the difference between sending the password and sending a link to reset the password, if an attacker has access to the victim's email? "Good thing no one needs this mediocre authentication method if SSL is available." Yeah, pity SSL is not an authentication method. You did know that, right? Digest authentication is heavily used in APIs and other non-browser applications, where you need some authentication but the tunnel is not necessary and you don't want to maintain heavy sessions. SSL, apart from NOT being an authentication method, is anyway slow and heavy and requires proper certs, so is mainly used only for user-facing web sites. Not to mention intranets, devices, etc. Anyway, even if HTTP Digest Auth were in fact rare, trying to wave it away with "good thing no-one needs it" is ridiculous. I, personally, need it, and am very far from alone. I'd like to mention that I do agree in principle, and am playing devil's advocate to some degree. My point is that password hashing is not a panacea, it is often not even possible, and I would certainly not avoid a site just because they store in plaintext if I otherwise had a good impression of their security practises. I suspect that many companies you know, trust and use have a plaintext copy of your password with them, and you wouldn't even know it.