"financial institutions often need to store in plaintext anyway, for telephone authentication."
Mine doesn't. And yes, if they did, I would not be their customer. Just because I may not know exactly what happens behind the scenes somewhere doesn't mean I can't react to the red flags I can see.
"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"
How is that any different than if the user can reset the password?
"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?"
There is a big difference. Anyone who has access to the text of the mail at any point in time now has your password. It's about mitigating the risks of the crappy vetting channel (email) with a time limited method (a reset URL).
"Yeah, pity SSL is not an authentication method. You did know that, right?"
For password based things, I am referring to the channel used to avoid the well known problems with digest access authentication such as man in the middle attacks.
Besides what I was referring to: used with non-anonymous X509 client certs, yes SSL is in fact used for authentication. Entire infrastructures are built on it. All of the clusters I have access to only let me in by virtue of X509 client certificates over SSL.
""good thing no-one needs it" is ridiculous. I, personally, need it, and am very far from alone."
I said good thing no one needs it if SSL is available not that no one needs it...
I use it myself in software we release that runs behind a firewall, I'm well aware it's cheaper.
"I would certainly not avoid a site just because they store in plaintext"
I admit it's a little on the reactionary side for me to say that, it was quick snarky comment.
Fair enough. I think we agree anyway, I'm just being difficult : )
"Mine doesn't. And yes, if they did, I would not be their customer."
Are you sure about that? However would you know? And how would they do telephone banking?
I wouldn't expect a bank to store plaintext either, I'd expect them to encrypt it and handle decryption at the terminal. But that's a whole different kettle of fish.
"Anyone who has access to the text of the mail at any point in time now has your password."
Yeah, there is no way I want my passwords going through email either. That argument was a bit flaky.
"avoid the well known problems with digest access authentication such as man in the middle attacks"
Your point is valid, but I wanted to respond by saying we're talking mainly about large-scale DB theft, 99 times out of 100 done by an insider. You seem to have experience inside a large organisation so you will know that often, SSL terminates at the load balancer, a password form will pass into the server from the balancer in plaintext. If there's an attacker on the inside, he can sniff that to his heart's content. You could argue Digest is actually more secure in this setting.
Toss up between more security on the user's LAN/WLAN (SSL) and more security inside the DC (Digest).. OK, this is a bit whimsical.
"All of the clusters I have access to only work by virtue of X509 client certificates over SSL"
Me too, actually. But, sadly, that's not appropriate for the public at large.
Anyway, I agree it's a red flag, just trying to make a point that it's not as black and white as it seemed you were suggesting. There can be good reasons to store in plaintext, and if it's carefully implemented I don't have a problem with it. As long as it's an informed choice, and not just a naive default, and that goes the other way as well.
It's a red flag, not an obsession...
"financial institutions often need to store in plaintext anyway, for telephone authentication."
Mine doesn't. And yes, if they did, I would not be their customer. Just because I may not know exactly what happens behind the scenes somewhere doesn't mean I can't react to the red flags I can see.
"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"
How is that any different than if the user can reset the password?
"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?"
There is a big difference. Anyone who has access to the text of the mail at any point in time now has your password. It's about mitigating the risks of the crappy vetting channel (email) with a time limited method (a reset URL).
"Yeah, pity SSL is not an authentication method. You did know that, right?"
For password based things, I am referring to the channel used to avoid the well known problems with digest access authentication such as man in the middle attacks.
Besides what I was referring to: used with non-anonymous X509 client certs, yes SSL is in fact used for authentication. Entire infrastructures are built on it. All of the clusters I have access to only let me in by virtue of X509 client certificates over SSL.
""good thing no-one needs it" is ridiculous. I, personally, need it, and am very far from alone."
I said good thing no one needs it if SSL is available not that no one needs it...
I use it myself in software we release that runs behind a firewall, I'm well aware it's cheaper.
"I would certainly not avoid a site just because they store in plaintext"
I admit it's a little on the reactionary side for me to say that, it was quick snarky comment.
But I don't take back that it's a red flag.