7 ms·

Can you trust 37signals with your password?

189 points by l0stman 17y ago

mpk 17y ago
Oh boy, that's an embarrassing newbie mistake to make.
- 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.
datums 17y ago
I would take it a step further. Why email plain text passwords? It usually stays in your inbox. This increase the chance of someone being able to get your password. It now exists on your laptop/desktop and on a email server, depending on your settings. There should be a reset password, but not a recover password. Send a link to a secure page which asks for something the user knows/has username ?
- cturner 17y ago
  Apple dev site does this.
- ErrantX 17y ago
  So many sites email your initial registration details to you in plain text. Even if they store them hashed up in future it's just a bad bad idea :( I know my damn password - I just typed it in :)
  - rythie 17y ago
    I know, it's really annoying MySpace do this
- tptacek 17y ago
  99% of the time, if you own the mail spool behind an account on a web application, you own the account, because of password reset.
  - cperciva 17y ago
    Yes, but with password reset you don't also own every other account the user has where they reused the same password.
    - tptacek 17y ago
      And? That has nothing to do with my point. I'm saying "the step forward" proposed upthread isn't one.
    - 17y ago
deleted 17y ago
[deleted]
bcl 17y ago
This kind of beginner mistake makes you wonder how 'hacker safe' their system really is. You can bet that they will be improving their security soon -- making bold claims about security is one way to guarantee lots of free pen testing.
- octane 17y ago
  > wonder how 'hacker safe' their system really is It's not. Not more than anyone else, anyway. 37signals and Fog Creek are masters of marketing and mind control. There are free tools, or at least superior commercial tools, that do everything their stuff does.
  - weaksauce 17y ago
    Care to expand on that? I am looking for something for team collaberation like basecamp and curious as to what is out there. I recommended basecamp to my boss to check out but after seeing this I am a little hesitant about it. Edit: I am hesitant because I cannot guarantee that all the users of basecamp will use a different password than the normal one for their email.
    - codemechanic 17y ago
      you can try Tonido workspace
crad 17y ago
One thing worth pointing out is he's saying that they're storing plain text in the database, which may not be the case. They may be storing the password in the database with two way encryption. I'm not arguing the merits of that, only pointing out he's claiming fact on something he has no specific details on.
- jonknee 17y ago
  If the server can decode it so can anyone who has access to the server. Not only that, but 37S reveals the password of other people's accounts to the admin. Pathetic.
  - deleted 17y ago
    [deleted]
  - tarmac 17y ago
    "If the server can decode it so can anyone who has access to the server." Semantics. Any type of security made by humans is breakable by humans. Your reasoning is flawed.
    - deleted 17y ago
      [deleted]
  - ramchip 17y ago
    "Pathetic." is a bit excessive...
    - jonknee 17y ago
      No, revealing people's passwords is pathetic. They are a multi-million dollar company, it's about time they Get Real.
- tarmac 17y ago
  Correct, the blog post is assuming the password is stored in plain text, when he doesn't even have hard evidence about it. Two way encryption would be an explanation to this, so I am waiting on what 37s' answer to this blog post. It's sad people quickly come to conclusions when only hearing one side of the story.
duncanj 17y ago
A long time ago I learned a technique where you use a random salt to add several bytes to a password. The salt is not stored, but rather the authenticating server does a brute-force search for it, using the user's password as a stem. For some reason, it just doesn't seem useful to me to store the salt with the user's record, if you're worried about someone with a rainbow crack running through your password file. Edit: that last paragraph was stupid.
- ryanwaggoner 17y ago
  You lost me...the way I've always seen salts used is just before hashing, but the same salt is used for all the passwords. Then when authenticating passwords, you salt & hash the incoming password and compare to the stored record in the DB. Am I doing it wrong?
  - jonknee 17y ago
    Using the same salt for all records makes it significantly easier for someone to crack your whole DB. A different salt for each row means they'd have to go through the effort of creating a rainbow table for each row instead of a whole database.
    - deleted 17y ago
      [deleted]
- cperciva 17y ago
  A long time ago I learned a technique where you use a random salt to add several bytes to a password. The salt is not stored, but rather the authenticating server does a brute-force search for it, using the user's password as a stem. This is called "key strengthening" and was proposed by Abadi et al. in 1997. It works, but it's not as secure as key stretching using a well designed key derivation function.
FraaJad 17y ago
reddit made this mistake early on and they learnt their lesson. They no longer store passwords in plain text. The popularity of a service does not guarantee that it's developers are covering all the bases. I'm glad Django stores all the passwords as a sha1 hash.
- cperciva 17y ago
  I'm glad Django stores all the passwords as a sha1 hash. This is better than storing plaintext passwords, but it still makes a brute-force attack very cheap. Use a well designed key derivation function which is expensive to attack. (And come to BSDCan'09 next week to hear me talk about this!)
  - simonw 17y ago
    Django uses a salted hash - each password is stored with a random hash code unique to that password, e.g.: sha1$0ae33$b8a9502237851f302170e1bb207d4eb3f36d9a31 The 0ae33 is different for each stored password, and is used as part of the SHA1 hash. This means you have to brute force each account separately - you can't just use a pre-generated SHA1 lookup table. It sounds like you know your stuff though - if there's anything we could do to make this secure (while not depending on any libraries other than the Python standard library) please share!
    - tptacek 17y ago
      That's still not secure, because SHA1 is very fast. To get "secure" from that, you need to iterate the function several thousand times, or use bcrypt.
      - cperciva 17y ago
        Or use scrypt, which is far more secure than bcrypt. :-)
      - FooBarWidget 17y ago
        Do you have a website or blog entry which explains in detail why using bcrypt is more secure than hash+salt, and how one is supposed to properly store passwords with crypt? Is it because Blowfish is more computationally expensive, and if so, how by how much compared to SHA-1? How does it compare to using larger hashes such as SHA-512 and Whirlpool? Why Blowfish instead of AES?
Batsu 17y ago
While it's important that the passwords aren't stored in plain text, it should be noted that it is also the last line of defense, not the first. There are plenty of other things to stop you on the way there (not having access to the email, not being able to crack into their data center, the normal stuff). Just because passwords are in plain text it doesn't mean that suddenly everyone is in trouble.
- jonknee 17y ago
  One of the most common ways for data to be stolen is from the inside. Having 500,000 user accounts with plain text passwords is a valuable commodity, all it takes is a pissed off employee and a SELECT email, username, password FROM users INTO OUTFILE '/tmp/users.txt'. Odds are you'd have access to tens of thousands of email addresses and from then on it's easy enough to crack tons of other accounts.
  - deleted 17y ago
    [deleted]
  - Batsu 17y ago
    Very true, and a point I didn't consider.
simonw 17y ago
Anyone know if 37signals still allow people to XSS their own Basecamp accounts? http://forum.37signals.com/basecamp/forums/5/topics/3155 http://forum.37signals.com/basecamp/forums/5/topics/3155
- 100k 17y ago
  I haven't used Basecamp in a while, but I was distressed to discover this when screwing around with HTML in todo lists a while back. I could put arbitrary JavaScript in the todo element, and I verified that it would execute when run by another user. Combine that with plain text password reset and you just got pwnd bad.
- harold 17y ago
  This thread on the 37 signals site infers that the administrator of a Basecamp account has access to the passwords of that account's users. Stewart the project manager now knows your password and that of everyone else on his team...
rythie 17y ago
Whilst doing hashed passwords is a no-brainer and it solves process problems like employees emailing passwords to people (who maybe impersonators) I don't think it solves all the problems with password security. Unless you have a strong password policy, john the ripper can often find several passwords (out of 100+) in literally a few seconds by doing dictionary attack, variants and common terms. I would say that someone's hashed password should be well protected as a unencrypted one would be even inside an organization.
- rythie 17y ago
  ...and your both downvoting this because you believe every security problem is solved by having hashed passwords? Another point is, do sites even protect against brute force remote hacking of passwords, Twitter for example got hacked that way. To be clear I believe they should hash their passwords, but it's not the only measure you should take.
ten7 17y ago
You said "37signals stores passwords in plain text in their database" You have no way of knowing how they store their data! And saying something like this is ludicrous and insulting, IMHo. Sure, they emailed you your password. That doesn't mean the password was stored in "plain text"... it just means it was stored. Yes, a one way hash would be better, but they stored the password. That doesn't mean the password was not encrypted when it was stored. It also does not mean the encryption key and the storage database are not on different servers -- which would be harder to crack, since it would mean two servers would have to be compromised. There is the possibility that they used two way encryption. That exists, you know... Just sayin'...
- thorax 17y ago
  Occam's razor says to me that if they didn't take the time to make one-way hashes, they're not doing anything especially clever with the storage. Certainly no dual-machine way of handling them because that's surely more complicated than using SHA1 or MD5.
jackowayed 17y ago
That doesn't necessarily mean that it's in plaintext. It could just be a 2-way encryption algorithm. That's what I did for my Twitter app pre-OAuth. That way, the passes are encrypted, but I could still decode them to send them to Twitter. Now, the way I did it, at least, the key for decrypting it was in my code, so if someone hacked, there's a good chance that they would look through the code and figure out what the algorithm was and what the code was. Still, if they just took the db and got out, and I fixed the hole before they realized it and came back, they would have a very hard time getting the passes. 37signals might be doing something like that, which is better than nothing. Now, they have no reason not to use a 1-way encryption algorithm, so it's still less secure than it should be.
- eli 17y ago
  Why go through the trouble of a "2-way" encryption scheme which, as you point out, could easily be compromised by someone with access to the server, instead of just storing a properly salted hash?
  - TJensen 17y ago
    Because he needs the plain-text password to send to twitter for auth.
slavingia 17y ago
obviouky. qhy da fuck not.
ErrantX 17y ago
The main securityy issue is not so much that the data is in plain text if extracted - it is the fact that it can be instanlty used. If you can only pull hashed, salted passwords from a site there is a LONG delay before you can make use of it, if at all. But with a plain text password a cracker can pull paswords, access accounts instanlty, harvest the data and potenetially ruin your site in minutes. There is no time delay in which potentially you can catch the intrusion. The defence by delay is one of the STRONGEST defence mechanisms you can have. Every day that data is unusable to a cracker the less value it has for him/her and the more chance the intrusion will be noticed.
psranga 17y ago
Protect yourself against lax companies like this with the PwdHash Firefox extension. http://www.pwdhash.com/ http://www.pwdhash.com/
pg 17y ago
I would have expected Rails libs to store hashes by default. Don't they?
- gry 17y ago
  Rails was extracted from Basecamp. The authentication mechanism is something of their own MVC design. The most popular authentication libraries do store salted nonce hashes by default.
madair 17y ago
LOL, a favorite like 37signals does something so egregiously wrong, is reported, and there's plenty of security 'experts' to say no big deal. This is a HUGE deal, and thanks to the OP for pointing it out. And you call yourselves experts. Note to self, be sure to avoid writings by Thomas Ptacek, if these are his standards.
davidw 17y ago
The comments are impressive... pretty much all of them are people rushing to the defense of 37 Signals.
- dabeeeenster 17y ago
  You must be new here... ;)
shalmanese 17y ago
People are missing the point. The main reason for this is not to defend against "hackers" so much as malicious employees within the company. If you hash and salt the passwords, it's simply not possible for anyone within the organization to access them. Even if you trust all your employees, it can help in avoiding liability.
dfranke 17y ago
Anyone who asserts in blanket terms that his application is secure is providing evidence to the contrary. Anyone who actually groks security won't make any such claim without loading it with carefully-chosen qualifiers.
geuis 17y ago
Military.com is another company that stores their passwords in plain text.

189 points by l0stman 17y ago

mpk 17y ago

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

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.

datums 17y ago

I would take it a step further. Why email plain text passwords? It usually stays in your inbox. This increase the chance of someone being able to get your password. It now exists on your laptop/desktop and on a email server, depending on your settings. There should be a reset password, but not a recover password. Send a link to a secure page which asks for something the user knows/has username ?

cturner 17y ago
Apple dev site does this.
ErrantX 17y ago
So many sites email your initial registration details to you in plain text. Even if they store them hashed up in future it's just a bad bad idea :( I know my damn password - I just typed it in :)
- rythie 17y ago
  I know, it's really annoying MySpace do this
tptacek 17y ago
99% of the time, if you own the mail spool behind an account on a web application, you own the account, because of password reset.
- cperciva 17y ago
  Yes, but with password reset you don't also own every other account the user has where they reused the same password.
  - tptacek 17y ago
    And? That has nothing to do with my point. I'm saying "the step forward" proposed upthread isn't one.
  - 17y ago

deleted 17y ago

[deleted]

bcl 17y ago

This kind of beginner mistake makes you wonder how 'hacker safe' their system really is. You can bet that they will be improving their security soon -- making bold claims about security is one way to guarantee lots of free pen testing.

octane 17y ago
> wonder how 'hacker safe' their system really is It's not. Not more than anyone else, anyway. 37signals and Fog Creek are masters of marketing and mind control. There are free tools, or at least superior commercial tools, that do everything their stuff does.
- weaksauce 17y ago
  Care to expand on that? I am looking for something for team collaberation like basecamp and curious as to what is out there. I recommended basecamp to my boss to check out but after seeing this I am a little hesitant about it. Edit: I am hesitant because I cannot guarantee that all the users of basecamp will use a different password than the normal one for their email.
  - codemechanic 17y ago
    you can try Tonido workspace

crad 17y ago

One thing worth pointing out is he's saying that they're storing plain text in the database, which may not be the case. They may be storing the password in the database with two way encryption. I'm not arguing the merits of that, only pointing out he's claiming fact on something he has no specific details on.

jonknee 17y ago
If the server can decode it so can anyone who has access to the server. Not only that, but 37S reveals the password of other people's accounts to the admin. Pathetic.
- deleted 17y ago
  [deleted]
- tarmac 17y ago
  "If the server can decode it so can anyone who has access to the server." Semantics. Any type of security made by humans is breakable by humans. Your reasoning is flawed.
  - deleted 17y ago
    [deleted]
- ramchip 17y ago
  "Pathetic." is a bit excessive...
  - jonknee 17y ago
    No, revealing people's passwords is pathetic. They are a multi-million dollar company, it's about time they Get Real.
tarmac 17y ago
Correct, the blog post is assuming the password is stored in plain text, when he doesn't even have hard evidence about it. Two way encryption would be an explanation to this, so I am waiting on what 37s' answer to this blog post. It's sad people quickly come to conclusions when only hearing one side of the story.

duncanj 17y ago

A long time ago I learned a technique where you use a random salt to add several bytes to a password. The salt is not stored, but rather the authenticating server does a brute-force search for it, using the user's password as a stem. For some reason, it just doesn't seem useful to me to store the salt with the user's record, if you're worried about someone with a rainbow crack running through your password file. Edit: that last paragraph was stupid.

ryanwaggoner 17y ago
You lost me...the way I've always seen salts used is just before hashing, but the same salt is used for all the passwords. Then when authenticating passwords, you salt & hash the incoming password and compare to the stored record in the DB. Am I doing it wrong?
- jonknee 17y ago
  Using the same salt for all records makes it significantly easier for someone to crack your whole DB. A different salt for each row means they'd have to go through the effort of creating a rainbow table for each row instead of a whole database.
  - deleted 17y ago
    [deleted]
cperciva 17y ago
A long time ago I learned a technique where you use a random salt to add several bytes to a password. The salt is not stored, but rather the authenticating server does a brute-force search for it, using the user's password as a stem. This is called "key strengthening" and was proposed by Abadi et al. in 1997. It works, but it's not as secure as key stretching using a well designed key derivation function.

FraaJad 17y ago

reddit made this mistake early on and they learnt their lesson. They no longer store passwords in plain text. The popularity of a service does not guarantee that it's developers are covering all the bases. I'm glad Django stores all the passwords as a sha1 hash.

cperciva 17y ago
I'm glad Django stores all the passwords as a sha1 hash. This is better than storing plaintext passwords, but it still makes a brute-force attack very cheap. Use a well designed key derivation function which is expensive to attack. (And come to BSDCan'09 next week to hear me talk about this!)
- simonw 17y ago
  Django uses a salted hash - each password is stored with a random hash code unique to that password, e.g.: sha1$0ae33$b8a9502237851f302170e1bb207d4eb3f36d9a31 The 0ae33 is different for each stored password, and is used as part of the SHA1 hash. This means you have to brute force each account separately - you can't just use a pre-generated SHA1 lookup table. It sounds like you know your stuff though - if there's anything we could do to make this secure (while not depending on any libraries other than the Python standard library) please share!
  - tptacek 17y ago
    That's still not secure, because SHA1 is very fast. To get "secure" from that, you need to iterate the function several thousand times, or use bcrypt.
    - cperciva 17y ago
      Or use scrypt, which is far more secure than bcrypt. :-)
    - FooBarWidget 17y ago
      Do you have a website or blog entry which explains in detail why using bcrypt is more secure than hash+salt, and how one is supposed to properly store passwords with crypt? Is it because Blowfish is more computationally expensive, and if so, how by how much compared to SHA-1? How does it compare to using larger hashes such as SHA-512 and Whirlpool? Why Blowfish instead of AES?

Batsu 17y ago

While it's important that the passwords aren't stored in plain text, it should be noted that it is also the last line of defense, not the first. There are plenty of other things to stop you on the way there (not having access to the email, not being able to crack into their data center, the normal stuff). Just because passwords are in plain text it doesn't mean that suddenly everyone is in trouble.

jonknee 17y ago
One of the most common ways for data to be stolen is from the inside. Having 500,000 user accounts with plain text passwords is a valuable commodity, all it takes is a pissed off employee and a SELECT email, username, password FROM users INTO OUTFILE '/tmp/users.txt'. Odds are you'd have access to tens of thousands of email addresses and from then on it's easy enough to crack tons of other accounts.
- deleted 17y ago
  [deleted]
- Batsu 17y ago
  Very true, and a point I didn't consider.

simonw 17y ago

Anyone know if 37signals still allow people to XSS their own Basecamp accounts? http://forum.37signals.com/basecamp/forums/5/topics/3155 http://forum.37signals.com/basecamp/forums/5/topics/3155

100k 17y ago
I haven't used Basecamp in a while, but I was distressed to discover this when screwing around with HTML in todo lists a while back. I could put arbitrary JavaScript in the todo element, and I verified that it would execute when run by another user. Combine that with plain text password reset and you just got pwnd bad.
harold 17y ago
This thread on the 37 signals site infers that the administrator of a Basecamp account has access to the passwords of that account's users. Stewart the project manager now knows your password and that of everyone else on his team...

rythie 17y ago

Whilst doing hashed passwords is a no-brainer and it solves process problems like employees emailing passwords to people (who maybe impersonators) I don't think it solves all the problems with password security. Unless you have a strong password policy, john the ripper can often find several passwords (out of 100+) in literally a few seconds by doing dictionary attack, variants and common terms. I would say that someone's hashed password should be well protected as a unencrypted one would be even inside an organization.

rythie 17y ago
...and your both downvoting this because you believe every security problem is solved by having hashed passwords? Another point is, do sites even protect against brute force remote hacking of passwords, Twitter for example got hacked that way. To be clear I believe they should hash their passwords, but it's not the only measure you should take.

ten7 17y ago

You said "37signals stores passwords in plain text in their database" You have no way of knowing how they store their data! And saying something like this is ludicrous and insulting, IMHo. Sure, they emailed you your password. That doesn't mean the password was stored in "plain text"... it just means it was stored. Yes, a one way hash would be better, but they stored the password. That doesn't mean the password was not encrypted when it was stored. It also does not mean the encryption key and the storage database are not on different servers -- which would be harder to crack, since it would mean two servers would have to be compromised. There is the possibility that they used two way encryption. That exists, you know... Just sayin'...

thorax 17y ago
Occam's razor says to me that if they didn't take the time to make one-way hashes, they're not doing anything especially clever with the storage. Certainly no dual-machine way of handling them because that's surely more complicated than using SHA1 or MD5.

jackowayed 17y ago

That doesn't necessarily mean that it's in plaintext. It could just be a 2-way encryption algorithm. That's what I did for my Twitter app pre-OAuth. That way, the passes are encrypted, but I could still decode them to send them to Twitter. Now, the way I did it, at least, the key for decrypting it was in my code, so if someone hacked, there's a good chance that they would look through the code and figure out what the algorithm was and what the code was. Still, if they just took the db and got out, and I fixed the hole before they realized it and came back, they would have a very hard time getting the passes. 37signals might be doing something like that, which is better than nothing. Now, they have no reason not to use a 1-way encryption algorithm, so it's still less secure than it should be.

eli 17y ago
Why go through the trouble of a "2-way" encryption scheme which, as you point out, could easily be compromised by someone with access to the server, instead of just storing a properly salted hash?
- TJensen 17y ago
  Because he needs the plain-text password to send to twitter for auth.

slavingia 17y ago

obviouky. qhy da fuck not.

ErrantX 17y ago

The main securityy issue is not so much that the data is in plain text if extracted - it is the fact that it can be instanlty used. If you can only pull hashed, salted passwords from a site there is a LONG delay before you can make use of it, if at all. But with a plain text password a cracker can pull paswords, access accounts instanlty, harvest the data and potenetially ruin your site in minutes. There is no time delay in which potentially you can catch the intrusion. The defence by delay is one of the STRONGEST defence mechanisms you can have. Every day that data is unusable to a cracker the less value it has for him/her and the more chance the intrusion will be noticed.

psranga 17y ago

Protect yourself against lax companies like this with the PwdHash Firefox extension. http://www.pwdhash.com/ http://www.pwdhash.com/

pg 17y ago

I would have expected Rails libs to store hashes by default. Don't they?

gry 17y ago
Rails was extracted from Basecamp. The authentication mechanism is something of their own MVC design. The most popular authentication libraries do store salted nonce hashes by default.

madair 17y ago

LOL, a favorite like 37signals does something so egregiously wrong, is reported, and there's plenty of security 'experts' to say no big deal. This is a HUGE deal, and thanks to the OP for pointing it out. And you call yourselves experts. Note to self, be sure to avoid writings by Thomas Ptacek, if these are his standards.

davidw 17y ago

The comments are impressive... pretty much all of them are people rushing to the defense of 37 Signals.

dabeeeenster 17y ago
You must be new here... ;)

shalmanese 17y ago

People are missing the point. The main reason for this is not to defend against "hackers" so much as malicious employees within the company. If you hash and salt the passwords, it's simply not possible for anyone within the organization to access them. Even if you trust all your employees, it can help in avoiding liability.

dfranke 17y ago

Anyone who asserts in blanket terms that his application is secure is providing evidence to the contrary. Anyone who actually groks security won't make any such claim without loading it with carefully-chosen qualifiers.

geuis 17y ago

Military.com is another company that stores their passwords in plain text.