7 ms·

Oh boy, that's an embarrassing newbie mistake to make.

by mpk 17y ago

ryanwaggoner 17y ago
What's worse is that they've known that it's an embarrassing security flaw for years, but they apparently thought other things were more important. Not really very comforting.
- tptacek 17y ago
  "Embarassing security flaw"? Come on. We audit several major web applications every week --- things that are far more sensitive than 37s, like banking, trading, and pension --- and we see sites store plaintext passwords all the time. I've never seen any vendor's security report write someone up for this. If it did get written up, it'd be "Severity: Low", along with "enabling weak SSL ciphers" and "exposed server version information". I'm not trying to be an apologist here, but "someone is wrong on the Internet" if they are saying that storing passwords badly is a major vulnerability.
  - sachinag 17y ago
    Really? We're going to downmod the most active security professional on HN? A guy who's built a 25+ person company on the basis of analyzing web applications for security? FFS, did we learn nothing from yesterday's expert kerfuffle? If Thomas says it's not really a big deal in practice, then it's not really a big deal in practice.
    - ryanwaggoner 17y ago
      On the contrary, it's a big deal to me because it's my password and I judge that it's being stored in an insecure manner. I really appreciate Thomas's expertise, but since my data is at risk as a customer, my opinion is really the one that counts.
      - axod 17y ago
        If you're not already using different passwords for each website, you can't really complain too much.
        ErrantX 17y ago
        but it's still the password for THAT site.
        axod 17y ago
        Sure, but if someones managed to hack into the server, they can steal your account regardless of if the password is plain text or not.
        mdg 17y ago
        no its cool, they use macs
    - tptacek 17y ago
      Note that I might not be "the most active security professional on HN", but am certainly "the security professional most active on HN". There's a big difference. ;) Note: I don't know who this "kubrick" person is, because he won't tell us, but "CISO of a financial institution or not", he's wrong about the OWASP Top 10. Neither "broken authentication" nor "poor encryption" "top vulnerabilities" discuss password encryption. "Storing plaintext passwords" is not an OWASP Top 10 flaw. "A7 Broken Authentication and Session Management" is a proxy for session fixation, and the catch-all category for things like "cookies that store the bit that tells the app whether you're the admin. It mentions passwords repeatedly without ever recommending they be encrypted; in fact, by talking about "Question and Answer" features, it tacitly acknowledges the practice. "A8 Insecure Cryptographic Storage" means "don't invent your own crypto", and now also "don't use MD5". It mentions passwords zero times; the only thing it says need to be encrypted are credit cards. This makes sense, because if it said anything else, no real-world web app would pass muster. Having said all that, I wouldn't put much stock in the OWASP Top 10 either. It's the most popular list of web flaws, but it isn't the most complete, nor is it the most coherent. It's not like there's science behind it.
    - kubrick 17y ago
      I've been in the security business for 15 years and have never heard of Thomas. I'm a CISSP, was a CISO of a financial institution for 6 years, and do professional security auditing. I don't care what this Thomas guys says -- if you don't believe me, believe OWASP (http://owasp.org/ http://owasp.org/) -- this is a serious and fundamental security problem.
  - shabda 17y ago
    Embarrassing as in known to everybody who builds web apps for a living and very easy to fix, and yet this way.
  - cool-RR 17y ago
    Do you believe there is any good reason for a site to store passwords in plaintext?
    - tptacek 17y ago
      No. 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.
      - ErrantX 17y ago
        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.
        tptacek 17y ago
        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.
  - cperciva 17y ago
    The fact that this is a common mistake doesn't make it any less serious. I don't do security audits, but if I did I would certainly point out this sort of mistake -- because even if it doesn't affect this site's security very much, it certainly has an impact on their customers' security thanks to the reuse of passwords.
    - tptacek 17y ago
      I'm going to have a hard time arguing that it isn't a mistake given my track record on the site. My only argument here is that, mistake or not --- it's definitely a mistake --- it's not a "serious security vulnerability", at least not as the industry understands them.
      - gmazzola 17y ago
        From a theoretical security perspective, it's a terrible idea to store passwords in plaintext, but again there's a difference between theory and practice as you've stated. If your auditing can reduce/eliminate unauthorized out-of-band database access, then in practice storing plaintext passwords isn't a huge problem. However, there's another practical aspect to consider: the password security of users. A perfect example from a month ago is a Christian dating website called Singles.org. The 4chan crowd discovered that if you replaced your user ID on the "profile edit" page with another user ID, you could edit another person's profile. The page also helpfully displayed the registered e-mail address and password, in plaintext. Now, this is terrible programming on multiple levels, so you might want to discount my anecdote, but the attack vector isn't my main point. The 4chan crowd, ravenous beasts that they were, attempted to use the Singles.org password to log into the victim's e-mail account. And their Facebook account. And their PayPal account. You can imagine the chaos they caused. The user base had terrible password security, so easily around 20% of the accounts had the same password across multiple websites. I don't think it's an uncommon statistic: sadly, even I as a security-conscious person have used the same password more than once. Our efforts should be to secure an application against all attack vectors, but hashing passwords is a veritable last defense to prevent an attack from spreading on to other websites. Regardless of how an application is exploited, it's a safe assumption that the users' poor password security could spread the attack further. I would thus claim that plaintext passwords be at least a "medium" security issue.
  - kubrick 17y ago
    This is a fundamental flaw. I'm a CISSP, a professional security auditor, a successful CISO, and I'd give this site a huge black mark if I was examining it. If this is "Severity: Low", why does OWASP list this flaw in not one but two of their top ten most common webapp security vulnerabilities? A7 - Broken Authentication and Session Management (http://www.owasp.org/index.php/Top_10_2007-A7 http://www.owasp.org/index.php/Top_10_2007-A7) A8 - Insecure Cryptographic Storage (http://www.owasp.org/index.php/Top_10_2007-A8 http://www.owasp.org/index.php/Top_10_2007-A8) It's a huge security flaw, enabling attackers to gain account access much more easily. If you really audit major web applications, then the someone who's "wrong on the Internet" has to be you. Seriously, take a look at a few well-respected books on the subject -- maybe this one http://www.webhackingexposed.com/ http://www.webhackingexposed.com/ and this one http://innocentcode.thathost.com/ http://innocentcode.thathost.com/ -- and rethink your position.
  - raganwald 17y ago
    I worked on a bank's web application and I recall our debating this very thing vigorously. We did have security audits, and if we did something like this we would expect the subject to come up in an audit. The reason we wouldn't have considered this to be a "major" security vulnerability is that compromising our database would already be a major catastrophe, so losing a few million people's passwords would be the least of our worries. So for a bank, it's like the old joke about not needing to run faster than a bear, just faster than your buddy. However, my guess is that 37Signals is a little different. We use campfire, but we do not discuss certain thing son it specifically because it is hosted on a 3rd party server. If 37Signals' database was compromised, we would be distressed to have our private conversations exposed, but we would be mortified if one of our developers' passwords was compromised and that became an attack vector into more sensitive information. So I am suggesting it comes down to relative vulnerability. For a bank, a compromised database is a catastrophe whether it contains plaintext passwords or not. For an online chat application, a compromised database is not a catastrophe, but compromising user passwords might tilt the balance from inconvenient to embarrassing. JM2C!
    - ErrantX 17y ago
      The slight fallacy there is assuming that it takes a full database compromise to extract the data. One of the things I have found is that often data (especially high-use data like passwords & usernames) is able to be snuck out through much more creative routes - storing in plaintext means extraction is much more worth the effort :) no waiting around to crack the data instant use.
      - raganwald 17y ago
        If I sneak the passwords out, can't I also sneak customer personal data like bank balances, SSNs, and so forth? Most banks maintain more than enough information on a customer to perform an identity theft and then some major fun begins such as misappropriating the title to real estate. I don't disagree it can be done, just pointing out that if we assume a compromised employee and a vector for removing the passwords, encrypting/hashing the passwords is like locking the side door of the stable.
  - ryanwaggoner 17y ago
    I didn't say it was a major vulnerability; I said it was embarrassing. Given 37signal's stature in the web community, the ease with which this problem can be fixed, the fact that they said they would fix it years ago and haven't, and the fact that this is a basic problem with a well-known solution, I think this is embarrassing for them.
  - thorax 17y ago
    I didn't expect to see a downplaying comment from you after your strong stances in this thread and your article: http://news.ycombinator.com/item?id=576021 http://news.ycombinator.com/item?id=576021 Is it a big deal to properly store the passwords or isn't it? > stop working on your social shopping cart calendar application right now: I can’t trust you with my Reddit karma score, let alone my credit card number. and that's what you said for developers using fast 1-way hashes. So it's embarrassing to use md5+salt, but not embarrassing to use plaintext? The method we use for storing passwords is either vital or it's not-- I'm currently lost as to how you could respond like the above and have such strong feelings about the matter in other discussions.
    - tptacek 17y ago
      Two thoughts I'm asking you to keep in your head simultaneously: (1) It is very bad to store passwords in plaintext, with a naked SHA1 hash, or with a naked SHA1 hash and a salt of any kind. (2) As bad as it is to do that, it is not a critical security vulnerability in your application to make that mistake. The classic web pester example of a "Medium" severity vulnerability: reflected cross-site scripting ("here, follow this link --- hah, now I own your session!"). If you tell me that reflected cross-site scripting is less bad --- or even the same level of bad --- as storing passwords poorly, I'll accuse you of being disingenuous. See downthread, upthread, and sidethread for examples of me pointing out my stance on safe password storage.
      - thorax 17y ago
        Sorry, man, I kind of can't take "disingenuous" accusations seriously as that was the word on the tip of my tongue when I read your surprising statement earlier in the thread. It doesn't sound like the same person I read before, nor from someone with your (deserved) status as a learned engineer on security matters. The point you disagreed with was whether this was an embarrassing security flaw: > "Embarassing security flaw"? Come on. and that's what I'm calling you on based on our earlier discussions. I'm not making any point about how this compares to other security flaws, I'm just trying to figure out where you really stand on plaintext. An earlier quote from you as I try to sort this out: > People get to access password hashes as soon as you mess up a single database query. The idea behind storing safe hashes is to prevent your stupid mistakes from screwing over every one of your users. The stupidest people of all are the ones who assume they aren't going to make stupid mistakes. So, the question at hand: Is it an embarrassing security flaw to use plaintext passwords for a modern, respected website?
- axod 17y ago
  If it was really a big security flaw, it would have been exploited in those 'several years'. Granted, it doesn't make you feel warm and fuzzy, but there's a lot worse.
  - gojomo 17y ago
    Famous last words: "If it was really big, it would have been exploited already." Never mind industry best practices or the cautionary incidents at other companies -- this "it's not big until it bites us" attitude can be used to deprioritize fixing any risky behavior until it's too late. There are low-stakes situations where this attitude is a virtue -- where the damage from an exploit is minor and quickly reversible. For famous and business-class internet services, the stakes are high.
- psranga 17y ago
  Just like Microsoft. :)
patio11 17y ago
In the same sense that my Japanese builder not using deadbolts and reinforced bars on the first floor windows, it is certainly a newbie mistake. Granted, there hasn't been a breakin in this ward in 5 years, but it could happen and then he'd be sorry he saved the $200 on his last 100 apartments. There are costs to absolutely everything, even doing the hashed password in the DB trick. Specifically, it puts one more bar in front of people logging into their account, particularly for some users who are habitually incapable of remembering their passwords and use the remember password link every single freaking time. (These people exist. Everyone collects stats, right?) You all know the conversion rate dieoff that happens as you add each additional form element to a checkout or survey form, right? And how increasing any funnel by a webpage increases the failure rate of the funnel, right? Well, imagine the equivalent of both adding an extra form element and an extra web access, right in the middle of the funnel, and if the user fails to get through the funnel they don't just bounce, they stop using your service for good. At 37Signals scales, losing half of the 10% or so of accounts which might need password recovery is worth a lot of money. At least several tens of thousands a year. That is an awfully big price to pay as the insurance premium against someone getting a full compromise of their database. (Though I'm sure their users would be grateful if the insurance worked. "Well, sucks that an unknown hacker has a tarball of all the business contacts I've ever put in your database. On the other hand, at least you didn't compromise my password -- my gmail remains safe!")
- cool-RR 17y ago
  What's the problem with a "reset password" option?
- simonw 17y ago
  I don't buy that argument. When someone clicks "I forgot my password", you e-mail them a one-time link to log in to their account. They click it, and they're in. That's easier than checking your e-mail and then typing a password. Not to mention that 37signals accounts are paid for - so there's a much higher incentive for people who forget their password to go through the flow to recover that account - otherwise they'll be wasting their money!
  - 17y ago
mtarnovan 17y ago
I doubt that this is a mistake in the sense of an unintentional oversight, but a deliberate design decision, albeit a poor one. They might have taken the KISS principle too far this time, at the expense of security.
tptacek 17y ago
You mean like FedEx and several banks? I don't love this design decision --- ok, no, wait, I hate this design decision --- but don't make it out to be something it isn't. The 37s team knows how to do "secure" password storage (that's every other Rails plugin ever written). They chose this because they thought it would make their customers lives easier.
- ryanwaggoner 17y ago
  Do you have any evidence of this? They said two years ago that they were going to change it...what makes you think it's not just a case of them being lazy?
- Hexstream 17y ago
  It is true that 37signals emphasizes making the lives of their customers easier. To a fault. But I don't see how the password recovery feature would be any less easy and convenient if it consisted of sending an email with a password reset link that brings you to a page where you just enter a new password twice and get logged in immediately. You have to deal with password reset link expiry and such but no big deal.
  - sgk284 17y ago
    A lot of people don't like changing passwords.
    - rufo 17y ago
      You don't have to change it. Type in the same password if you really want. Of course, if you knew what the password was in the first place, you wouldn't have needed to reset your password...
      - thaumaturgy 17y ago
        I can come at this from the other end: part of my consulting deals with end-users on a daily basis, and I've seen even novice users _finally_ starting to use multiple passwords on their own without prompting. So, it more likely would be a simple case of their forgetting which password they used on that particular system.
tjogin 17y ago
Instead of trusting every single provider of a service you use to safekeep your password, why not just use unique passwords for each service? I mean, really, you can't put the blame on each of the service providers if you choose to use the same password everywhere. That, if anything, is an embarrassing newbie mistake. I have a repeatable method of coming up with a unique password for each service. I don't have to remember each unique password, only my method for producing a password. Because my method is arbitrary rather than mathematic, I don't think anyone can figure it out even if given sample of passwords (I've challenged several who claim to be able to do so "easily"). And while my method is arbitrary, it's comprised of a few rules I know very well, which leads me to actually remember each unique password fairly well. Don't outsource the job of safekeeping your password to every single vendor out there. Do it yourself.

Oh boy, that's an embarrassing newbie mistake to make.

by mpk 17y ago

Oh boy, that's an embarrassing newbie mistake to make.

What's worse is that they've known that it's an embarrassing security flaw for years, but they apparently thought other things were more important. Not really very comforting.

tptacek 17y ago
"Embarassing security flaw"? Come on. We audit several major web applications every week --- things that are far more sensitive than 37s, like banking, trading, and pension --- and we see sites store plaintext passwords all the time. I've never seen any vendor's security report write someone up for this. If it did get written up, it'd be "Severity: Low", along with "enabling weak SSL ciphers" and "exposed server version information". I'm not trying to be an apologist here, but "someone is wrong on the Internet" if they are saying that storing passwords badly is a major vulnerability.
- sachinag 17y ago
  Really? We're going to downmod the most active security professional on HN? A guy who's built a 25+ person company on the basis of analyzing web applications for security? FFS, did we learn nothing from yesterday's expert kerfuffle? If Thomas says it's not really a big deal in practice, then it's not really a big deal in practice.
  - ryanwaggoner 17y ago
    On the contrary, it's a big deal to me because it's my password and I judge that it's being stored in an insecure manner. I really appreciate Thomas's expertise, but since my data is at risk as a customer, my opinion is really the one that counts.
    - axod 17y ago
      If you're not already using different passwords for each website, you can't really complain too much.
      - ErrantX 17y ago
        but it's still the password for THAT site.
        axod 17y ago
        Sure, but if someones managed to hack into the server, they can steal your account regardless of if the password is plain text or not.
        mdg 17y ago
        no its cool, they use macs
  - tptacek 17y ago
    Note that I might not be "the most active security professional on HN", but am certainly "the security professional most active on HN". There's a big difference. ;) Note: I don't know who this "kubrick" person is, because he won't tell us, but "CISO of a financial institution or not", he's wrong about the OWASP Top 10. Neither "broken authentication" nor "poor encryption" "top vulnerabilities" discuss password encryption. "Storing plaintext passwords" is not an OWASP Top 10 flaw. "A7 Broken Authentication and Session Management" is a proxy for session fixation, and the catch-all category for things like "cookies that store the bit that tells the app whether you're the admin. It mentions passwords repeatedly without ever recommending they be encrypted; in fact, by talking about "Question and Answer" features, it tacitly acknowledges the practice. "A8 Insecure Cryptographic Storage" means "don't invent your own crypto", and now also "don't use MD5". It mentions passwords zero times; the only thing it says need to be encrypted are credit cards. This makes sense, because if it said anything else, no real-world web app would pass muster. Having said all that, I wouldn't put much stock in the OWASP Top 10 either. It's the most popular list of web flaws, but it isn't the most complete, nor is it the most coherent. It's not like there's science behind it.
  - kubrick 17y ago
    I've been in the security business for 15 years and have never heard of Thomas. I'm a CISSP, was a CISO of a financial institution for 6 years, and do professional security auditing. I don't care what this Thomas guys says -- if you don't believe me, believe OWASP (http://owasp.org/ http://owasp.org/) -- this is a serious and fundamental security problem.
- shabda 17y ago
  Embarrassing as in known to everybody who builds web apps for a living and very easy to fix, and yet this way.
- cool-RR 17y ago
  Do you believe there is any good reason for a site to store passwords in plaintext?
  - tptacek 17y ago
    No. 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.
    - ErrantX 17y ago
      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.
      - tptacek 17y ago
        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.
- cperciva 17y ago
  The fact that this is a common mistake doesn't make it any less serious. I don't do security audits, but if I did I would certainly point out this sort of mistake -- because even if it doesn't affect this site's security very much, it certainly has an impact on their customers' security thanks to the reuse of passwords.
  - tptacek 17y ago
    I'm going to have a hard time arguing that it isn't a mistake given my track record on the site. My only argument here is that, mistake or not --- it's definitely a mistake --- it's not a "serious security vulnerability", at least not as the industry understands them.
    - gmazzola 17y ago
      From a theoretical security perspective, it's a terrible idea to store passwords in plaintext, but again there's a difference between theory and practice as you've stated. If your auditing can reduce/eliminate unauthorized out-of-band database access, then in practice storing plaintext passwords isn't a huge problem. However, there's another practical aspect to consider: the password security of users. A perfect example from a month ago is a Christian dating website called Singles.org. The 4chan crowd discovered that if you replaced your user ID on the "profile edit" page with another user ID, you could edit another person's profile. The page also helpfully displayed the registered e-mail address and password, in plaintext. Now, this is terrible programming on multiple levels, so you might want to discount my anecdote, but the attack vector isn't my main point. The 4chan crowd, ravenous beasts that they were, attempted to use the Singles.org password to log into the victim's e-mail account. And their Facebook account. And their PayPal account. You can imagine the chaos they caused. The user base had terrible password security, so easily around 20% of the accounts had the same password across multiple websites. I don't think it's an uncommon statistic: sadly, even I as a security-conscious person have used the same password more than once. Our efforts should be to secure an application against all attack vectors, but hashing passwords is a veritable last defense to prevent an attack from spreading on to other websites. Regardless of how an application is exploited, it's a safe assumption that the users' poor password security could spread the attack further. I would thus claim that plaintext passwords be at least a "medium" security issue.
- kubrick 17y ago
  This is a fundamental flaw. I'm a CISSP, a professional security auditor, a successful CISO, and I'd give this site a huge black mark if I was examining it. If this is "Severity: Low", why does OWASP list this flaw in not one but two of their top ten most common webapp security vulnerabilities? A7 - Broken Authentication and Session Management (http://www.owasp.org/index.php/Top_10_2007-A7 http://www.owasp.org/index.php/Top_10_2007-A7) A8 - Insecure Cryptographic Storage (http://www.owasp.org/index.php/Top_10_2007-A8 http://www.owasp.org/index.php/Top_10_2007-A8) It's a huge security flaw, enabling attackers to gain account access much more easily. If you really audit major web applications, then the someone who's "wrong on the Internet" has to be you. Seriously, take a look at a few well-respected books on the subject -- maybe this one http://www.webhackingexposed.com/ http://www.webhackingexposed.com/ and this one http://innocentcode.thathost.com/ http://innocentcode.thathost.com/ -- and rethink your position.
- raganwald 17y ago
  I worked on a bank's web application and I recall our debating this very thing vigorously. We did have security audits, and if we did something like this we would expect the subject to come up in an audit. The reason we wouldn't have considered this to be a "major" security vulnerability is that compromising our database would already be a major catastrophe, so losing a few million people's passwords would be the least of our worries. So for a bank, it's like the old joke about not needing to run faster than a bear, just faster than your buddy. However, my guess is that 37Signals is a little different. We use campfire, but we do not discuss certain thing son it specifically because it is hosted on a 3rd party server. If 37Signals' database was compromised, we would be distressed to have our private conversations exposed, but we would be mortified if one of our developers' passwords was compromised and that became an attack vector into more sensitive information. So I am suggesting it comes down to relative vulnerability. For a bank, a compromised database is a catastrophe whether it contains plaintext passwords or not. For an online chat application, a compromised database is not a catastrophe, but compromising user passwords might tilt the balance from inconvenient to embarrassing. JM2C!
  - ErrantX 17y ago
    The slight fallacy there is assuming that it takes a full database compromise to extract the data. One of the things I have found is that often data (especially high-use data like passwords & usernames) is able to be snuck out through much more creative routes - storing in plaintext means extraction is much more worth the effort :) no waiting around to crack the data instant use.
    - raganwald 17y ago
      If I sneak the passwords out, can't I also sneak customer personal data like bank balances, SSNs, and so forth? Most banks maintain more than enough information on a customer to perform an identity theft and then some major fun begins such as misappropriating the title to real estate. I don't disagree it can be done, just pointing out that if we assume a compromised employee and a vector for removing the passwords, encrypting/hashing the passwords is like locking the side door of the stable.
- ryanwaggoner 17y ago
  I didn't say it was a major vulnerability; I said it was embarrassing. Given 37signal's stature in the web community, the ease with which this problem can be fixed, the fact that they said they would fix it years ago and haven't, and the fact that this is a basic problem with a well-known solution, I think this is embarrassing for them.
- thorax 17y ago
  I didn't expect to see a downplaying comment from you after your strong stances in this thread and your article: http://news.ycombinator.com/item?id=576021 http://news.ycombinator.com/item?id=576021 Is it a big deal to properly store the passwords or isn't it? > stop working on your social shopping cart calendar application right now: I can’t trust you with my Reddit karma score, let alone my credit card number. and that's what you said for developers using fast 1-way hashes. So it's embarrassing to use md5+salt, but not embarrassing to use plaintext? The method we use for storing passwords is either vital or it's not-- I'm currently lost as to how you could respond like the above and have such strong feelings about the matter in other discussions.
  - tptacek 17y ago
    Two thoughts I'm asking you to keep in your head simultaneously: (1) It is very bad to store passwords in plaintext, with a naked SHA1 hash, or with a naked SHA1 hash and a salt of any kind. (2) As bad as it is to do that, it is not a critical security vulnerability in your application to make that mistake. The classic web pester example of a "Medium" severity vulnerability: reflected cross-site scripting ("here, follow this link --- hah, now I own your session!"). If you tell me that reflected cross-site scripting is less bad --- or even the same level of bad --- as storing passwords poorly, I'll accuse you of being disingenuous. See downthread, upthread, and sidethread for examples of me pointing out my stance on safe password storage.
    - thorax 17y ago
      Sorry, man, I kind of can't take "disingenuous" accusations seriously as that was the word on the tip of my tongue when I read your surprising statement earlier in the thread. It doesn't sound like the same person I read before, nor from someone with your (deserved) status as a learned engineer on security matters. The point you disagreed with was whether this was an embarrassing security flaw: > "Embarassing security flaw"? Come on. and that's what I'm calling you on based on our earlier discussions. I'm not making any point about how this compares to other security flaws, I'm just trying to figure out where you really stand on plaintext. An earlier quote from you as I try to sort this out: > People get to access password hashes as soon as you mess up a single database query. The idea behind storing safe hashes is to prevent your stupid mistakes from screwing over every one of your users. The stupidest people of all are the ones who assume they aren't going to make stupid mistakes. So, the question at hand: Is it an embarrassing security flaw to use plaintext passwords for a modern, respected website?
axod 17y ago
If it was really a big security flaw, it would have been exploited in those 'several years'. Granted, it doesn't make you feel warm and fuzzy, but there's a lot worse.
- gojomo 17y ago
  Famous last words: "If it was really big, it would have been exploited already." Never mind industry best practices or the cautionary incidents at other companies -- this "it's not big until it bites us" attitude can be used to deprioritize fixing any risky behavior until it's too late. There are low-stakes situations where this attitude is a virtue -- where the damage from an exploit is minor and quickly reversible. For famous and business-class internet services, the stakes are high.
psranga 17y ago
Just like Microsoft. :)

patio11 17y ago

In the same sense that my Japanese builder not using deadbolts and reinforced bars on the first floor windows, it is certainly a newbie mistake. Granted, there hasn't been a breakin in this ward in 5 years, but it could happen and then he'd be sorry he saved the $200 on his last 100 apartments. There are costs to absolutely everything, even doing the hashed password in the DB trick. Specifically, it puts one more bar in front of people logging into their account, particularly for some users who are habitually incapable of remembering their passwords and use the remember password link every single freaking time. (These people exist. Everyone collects stats, right?) You all know the conversion rate dieoff that happens as you add each additional form element to a checkout or survey form, right? And how increasing any funnel by a webpage increases the failure rate of the funnel, right? Well, imagine the equivalent of both adding an extra form element and an extra web access, right in the middle of the funnel, and if the user fails to get through the funnel they don't just bounce, they stop using your service for good. At 37Signals scales, losing half of the 10% or so of accounts which might need password recovery is worth a lot of money. At least several tens of thousands a year. That is an awfully big price to pay as the insurance premium against someone getting a full compromise of their database. (Though I'm sure their users would be grateful if the insurance worked. "Well, sucks that an unknown hacker has a tarball of all the business contacts I've ever put in your database. On the other hand, at least you didn't compromise my password -- my gmail remains safe!")

cool-RR 17y ago
What's the problem with a "reset password" option?
simonw 17y ago
I don't buy that argument. When someone clicks "I forgot my password", you e-mail them a one-time link to log in to their account. They click it, and they're in. That's easier than checking your e-mail and then typing a password. Not to mention that 37signals accounts are paid for - so there's a much higher incentive for people who forget their password to go through the flow to recover that account - otherwise they'll be wasting their money!
- 17y ago

mtarnovan 17y ago

I doubt that this is a mistake in the sense of an unintentional oversight, but a deliberate design decision, albeit a poor one. They might have taken the KISS principle too far this time, at the expense of security.

tptacek 17y ago

You mean like FedEx and several banks? I don't love this design decision --- ok, no, wait, I hate this design decision --- but don't make it out to be something it isn't. The 37s team knows how to do "secure" password storage (that's every other Rails plugin ever written). They chose this because they thought it would make their customers lives easier.

ryanwaggoner 17y ago
Do you have any evidence of this? They said two years ago that they were going to change it...what makes you think it's not just a case of them being lazy?
Hexstream 17y ago
It is true that 37signals emphasizes making the lives of their customers easier. To a fault. But I don't see how the password recovery feature would be any less easy and convenient if it consisted of sending an email with a password reset link that brings you to a page where you just enter a new password twice and get logged in immediately. You have to deal with password reset link expiry and such but no big deal.
- sgk284 17y ago
  A lot of people don't like changing passwords.
  - rufo 17y ago
    You don't have to change it. Type in the same password if you really want. Of course, if you knew what the password was in the first place, you wouldn't have needed to reset your password...
    - thaumaturgy 17y ago
      I can come at this from the other end: part of my consulting deals with end-users on a daily basis, and I've seen even novice users _finally_ starting to use multiple passwords on their own without prompting. So, it more likely would be a simple case of their forgetting which password they used on that particular system.

tjogin 17y ago

Instead of trusting every single provider of a service you use to safekeep your password, why not just use unique passwords for each service? I mean, really, you can't put the blame on each of the service providers if you choose to use the same password everywhere. That, if anything, is an embarrassing newbie mistake. I have a repeatable method of coming up with a unique password for each service. I don't have to remember each unique password, only my method for producing a password. Because my method is arbitrary rather than mathematic, I don't think anyone can figure it out even if given sample of passwords (I've challenged several who claim to be able to do so "easily"). And while my method is arbitrary, it's comprised of a few rules I know very well, which leads me to actually remember each unique password fairly well. Don't outsource the job of safekeeping your password to every single vendor out there. Do it yourself.