Progressive postal-mailed me a letter with password on it when they sent my first insurance cards.
I think some health insurance sites do the same thing.
Bad Security at Evite
11–20 of 23 posts
Re: Bad Security at Evite
#12Didn't we have this discussion about password hashing already a few weeks ago? If someone's snooping on your email, I think you've got bigger problems than a lost password, tbh. As for hashing, again, if someone can get on the server and download the whole database, you've got bigger problems than password hashing. I'm not saying this is a good practice, but I just don't think it's as big a problem as this guy is mak…
It's a really big problem. If you lose your whole database to an attacker, you have a big problem. If you lose your whole database to an attacker, and you stored recoverable passwords in it, everyone has a big problem. There'd be something to debate here if fixing this problem wasn't 5-10 lines of code. But that's what it is. 5-10 lines of code to keep yourself from compromising tens of thousands of (email, password)…
I agree that storing passwords in plaintext is an anti pattern. But with a one-way-password-encryption setup you need a password resetting system, which is more than 5-10 lines of code.
Re: Bad Security at Evite
#13Earlier quoted context omitted.
It's a really big problem. If you lose your whole database to an attacker, you have a big problem. If you lose your whole database to an attacker, and you stored recoverable passwords in it, everyone has a big problem. There'd be something to debate here if fixing this problem wasn't 5-10 lines of code. But that's what it is. 5-10 lines of code to keep yourself from compromising tens of thousands of (email, password)…
I agree that storing passwords in plaintext is an anti pattern. But with a one-way-password-encryption setup you need a password resetting system, which is more than 5-10 lines of code.
You need many of those same lines of code to do password recovery if you store plaintext.
Re: Bad Security at Evite
#14Earlier quoted context omitted.
True, two way hashing is better than nothing, but it's still less secure than one way hashing (with a per-user salt) for passwords. All you need if one rogue employee and they can decrypt everyone's password. It's just difficult to justify the added risk when there usually isn't a need to retrieve the original password. Edit: by "two way hashing" I meant encryption, not hashing. not sure where my brain was on that on…
As a practitioner in this space, I'm going to tell you that I don't know what this "two-way hashing" is that you speak of. There's a right way to store passwords and there's a wrong way. The right way is bcrypt. The wrong way is anything other than bcrypt.
Are you making a distinction between storing for verification and storing for use? The right way to store passwords when you use them to verify authentication is to hash (twitter verifying a login). The right way to store passwords when you need to use them to gain access on behalf of a user is to encrypt them (any third party "twitter application"). I ask because the first google result for "bcrypt" is http://bcrypt.sourceforge.net/ which is distinctly not hashing, where as the second one is for a ruby library interface to bcrypt hashing.
Re: Bad Security at Evite
#15Sending your password after signup doesn't necessarily mean they're storing it permanently.
And it doesn't mean they're storing it in cleartext either. For some reason I don't think he'd understand how virtual attributes work, though...
Re: Bad Security at Evite
#16Evite is willing to sacrifice security for usability. Which makes sense, because it doesn't really matter if someone hacks your Evite account.
Re: Bad Security at Evite
#17Earlier quoted context omitted.
As a practitioner in this space, I'm going to tell you that I don't know what this "two-way hashing" is that you speak of. There's a right way to store passwords and there's a wrong way. The right way is bcrypt. The wrong way is anything other than bcrypt.
Are you making a distinction between storing for verification and storing for use? The right way to store passwords when you use them to verify authentication is to hash (twitter verifying a login). The right way to store passwords when you need to use them to gain access on behalf of a user is to encrypt them (any third party "twitter application"). I ask because the first google result for "bcrypt" is http://bcrypt…
First, bcrypt is a one-way hash algorithm.
Second, the whole fuss about Twitter and OAuth is the degree to which people are not OK with giving their passwords to other people to use.
Re: Bad Security at Evite
#18Sending your password after signup doesn't necessarily mean they're storing it permanently.
You're absolutely correct, but in evite's case they are storing them permanently. That's actually the reason I posted this was that I forgot my password and requested a reset (~5 years after signup) and they sent it to me in plain text.
Re: Bad Security at Evite
#19Evite is willing to sacrifice security for usability. Which makes sense, because it doesn't really matter if someone hacks your Evite account.
I don't think hacking the evite account is the problem. With many people using the same password across multiple accounts, getting their evite password may also be giving the password to countless other systems. So they are essentially sacrificing the security of their users, not just their own application.
Re: Bad Security at Evite
#20Evite is willing to sacrifice security for usability. Which makes sense, because it doesn't really matter if someone hacks your Evite account.
I don't think hacking the evite account is the problem. With many people using the same password across multiple accounts, getting their evite password may also be giving the password to countless other systems. So they are essentially sacrificing the security of their users, not just their own application.
I agree that people do that, and that ideally a website would would not email someone their password for the simple reason that people do recycle passwords.
But, the onus here should really be on the user. If they are careless enough to use the same password for everything, they are indicating that they are willing to trade some security for convenience. In my opinion, emailing users their password is just another security/convenience trade-off. I'd be upset to get my password sent in plantext from my bank, but not an invite website.