I'm actually bizarrely fixated on this topic; go to "searchyc.com" and search for "bcrypt" and follow the threads. It is, apparently, all I ever talk about.
I'm not defending the feature. I'm just saying:
* Lots of companies have this feature.
* Among them are FedEx and several banks.
* If you wrote a security report for Basecamp and included this problem at all, it would be "Severity: Low". I'd write it up. But I wouldn't say "Severity: Critical", because I would get my ass kicked by my clients and partners.
The rest of this debate, have at it. I agree. BURN THE WITCHES.
Well also as a security professional (also called Thomas as it happens :P small world) I would point it out as at least a medium security flaw.
> because I would get my ass kicked by my clients and partners.
So your reasoning is nothing to do with security - it is to do with saying what the customer wants to hear (low severity stuff can be ignored, right?).
I have found the opposite in the past: encrypting passwords is, I agree, a common issue and one that is also usually very simple to fix. You can present that whole fix to the client and it can probably be implemented in a few weeks/months - it's useful because it is not something that will send them screaming to the hills but it is something so they feel they are getting value for money :) (plus you will likely get follow up work - if not to fix the problem then to audit the fixes!). Win win.
At the end of the day storing in plain text means it only takes on slip to release all your users passwords into the wild. It IS a big security flaw. If I walk away from an audit w/o flagging the password encryption as something to be addressed fairly soon and then the passwords are stolen my ass is properly on the line (probably more than any other issue).
And for the record I am talking as big if not bigger institutions than Fedex and US banks.
My reasoning is that usually we call out things that can actually allow an attacker to compromise the site, and don't spend as much time on the million things that might make an attacker's life easier after that compromise has occurred.
The rest of your argument is a moot point, because I'm not asserting that passwords should be stored plaintext.
It's not really moot because I never assumed you were asserting that.
But you did just say that you would either not mention or flag as low priority (and the suggestion is grudgingly) a plain text passwords issue because "I would get my ass kicked by my clients and partners". I'll be honest - I wouldn't hire you if I had seen that written publicly like that :(
I sometimes think that one of the major failings in our industry is that we toe the corporate line and never stop to think like a cracker. That's why I have my job - because I do. Some people see plain text passwords as a "making life easier" issue, whereas for me it is a major weakness at the core of the security chain. Throw all you like in the way but, at the end of that day, the passwords are there in clear text waiting for me to find it. It doesn't matter how many different ways I can or cant compromise a site: all I need to do is do it once...
And anyway, my point was less about this specific issue than about how I think you address it wrong. The hashed passwords issue is one you can dress up for a client so they think they get value for money. If they get nothing except a green tick on the "critical errors" page then you leave them with the feeling that they are missing something. Hashing passwords should be fixed - and we can get them to fix it. And at the same time they get something meaningful from their audit :)
* The probability of your servers getting hacked/stolen is reasonably low as long as you take other precautions.
For most people, I'd say it's a lot of extra work, for no real pay-off - apart from making your users feel a bit more warm and fuzzy.
A better solution would probably just be a disclaimer on websites saying "Please don't use the same password you use for online banking here, as that would be silly".
