"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.
"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.
"First, the finserv organizations we've worked with tend not to store plaintext passwords."
I am talking about retail banking, specifically those with telephone service. If they don't store in a recoverable form (encrypted or plaintext) then I would love to know how the telephone operators verify passwords.
"Secondly, the difference between sending the password and the reset link in email is that the former compromises every other app the user uses."
Sorry, I don't understand the meaning of this sentence.
Anyway, I wasn't really serious with the "password recovery by email" argument, I was just trying to come up with a list of reasons an org might want to store plaintext, but that was probably a pretty flaky one. Any site that sent me my password in plaintext via unencrypted mail would lose me as a customer pretty damn quickly, too.
I meant encrypted for banking, of course. The key point being that the passwords are readable. Two-way, vs the one-way hash discussed before. Maybe I didn't explain myself properly.
Web site passwords might be one-way hashed, I don't know, but telephone banking passwords must be displayed on screen for the operator to read.
"Use of HTTP Auth --- digest or otherwise --- at all --- a doc-able finding."
Uh-huh. So, your photocopiers have SSL certs do they? More likely they have nothing at all. I wonder if that's a "doc-able finding", whatever that is, presumably something bad.
This obsession with HTTP Auth being "evil" is laughable. A lot of the time it's absolutely fine. Hell, a lot of the time it's overkill.
And that rule, if true, is a Dilbert-esque joke. You can't legislate security by banning arbitrary protocols like that. Yes SSL is more secure but other methodologies are still useful, used appropriately. It's like the army banning pistols because machine guns are "better".
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.