4 ms·

I doubt that. They're led by probably the strongest Rails team anywhere, and they (DHH + team) wrote books on avoiding what RockYou just did. EDIT: I'm specifi

by tree5 17y ago

I doubt that. They're led by probably the strongest Rails team anywhere, and they (DHH + team) wrote books on avoiding what RockYou just did. EDIT: I'm specifically referring to DHH's "Agile Web Development With Rails", Chapter 11, Administration

tsally 17y ago
It happened (storing in plaintext, not losing the actual passwords): http://www.jgc.org/blog/2009/05/can-you-trust-37signals-with-your.html http://www.jgc.org/blog/2009/05/can-you-trust-37signals-with... We've covered 37signals poor approach to security before: http://news.ycombinator.com/item?id=804257 http://news.ycombinator.com/item?id=804257 It's my understanding that they've since reformed. I'd be interested in what books you think they've written that provide credible security advice. Blind "fanboyism" (if I may invent a word) is a bad thing.
- tree5 17y ago
  "Agile Web Development With Rails", Chapter 11, Administration
  - tsally 17y ago
    Here's the sample code they give in that chapter: def self.encrypted_password(password, salt) string_to_hash = password + "wibble" + salt # 'wibble' makes it harder to guess Digest::SHA1.hexdigest(string_to_hash) end They are using SHA1 with a salt, the exact method that security experts recommend against when storing passwords: http://news.ycombinator.com/item?id=995645 http://news.ycombinator.com/item?id=995645. And obviously they didn't even use this insecure method internally. EDIT: tptacek makes a good point. I haven't quite been fair. 37signals did what most companies never do when confronted with a security issue: they quickly acknowledged the problem, fixed it based on the suggestions of the security researchers, and moved on.
    - tptacek 17y ago
      You're right. Just give them credit for taking their lumps, apologizing, and getting religion.
- cloudkj 17y ago
  I'm guessing tree5 is talking about "Agile Web Development With Rails," in which the authors do give examples of creating hashed passwords with a unique salt and running a SHA1 digest. The book also talks about preventing plain text passwords from showing up in log files from form submissions. From what I understand however, AWDWR is only tangentially related to 37signals.
- tptacek 17y ago
  There is a difference between storing plaintext passwords and actually losing them, and as much as I hate to give someone a pass on insecure password storage (it is, apparently, all I ever talk about here), you have to be intellectually honest. And, like I say every time this comes up, FedEx and several banks also store plaintext passwords. 37signals no longer stores easily attacked passwords.
  - tsally 17y ago
    There is a difference between storing plaintext passwords and actually losing them, and as much as I hate to give someone a pass on insecure password storage (it is, apparently, all I ever talk about here), you have to be intellectually honest. I was intellectually honest. I explicitly said they didn't actually lose them. 37signals no longer stores easily attacked passwords. I was under the impression that this was true as well. However I just checked and I got my Backpack password emailed to me in plain text. So at least the Backpack application is still incorrect.
    - tptacek 17y ago
      Either they haven't gotten to you in the rollout yet, or they aren't doing Backpack (which would surprise me). The "honesty" comment wasn't directed to you, but it's obvious why you would think it was. Sorry.
      - tsally 17y ago
        The "honesty" comment wasn't directed to you, but it's obvious why you would think it was. Sorry. Given your history of quality and logical posts, I pretty much knew the comment wasn't directed towards me. I just wanted to go on record to be sure. I'm sorry as well, I should have just let it fly. Either they haven't gotten to you in the rollout yet, or they aren't doing Backpack (which would surprise me). They're launching unified accounts soon for all services (you have to pick a new user name and password if I remember correctly). Perhaps this is when they'll roll out the password security? Seems like a logical time to me.
- epochwolf 17y ago
  Both of those links are not proof of any lax security at 37signals. The first link makes the assumption that the ability to email a user's password means the passwords are in plain text. There is such as thing as secure two-way encryption. (Granted, if the hacker gets the encryption key, you're hosed.) You can read more about that in the comments on that blog. [ignore] The second link is about a security problem in ruby on rails. Unfortunately ruby doesn't have proper utf-8 support so ruby on rails needs to monkey-patch the ruby string classes to provide proper support. It is unsurprising that there was a bug in this patching. This is a framework issue that has nothing to do with 37signal's security practices. Hindsight is 20/20. Frameworks always end up with security issues. At least you can see that it's been fixed for some time. Okay, issue was with the lack of a secure channel. Point taken. That was a mistake. [Removed section on procedures and mistakes, as non-relavent.] (Disclosure: I use ruby on rails)
  - tsally 17y ago
    The first link makes the assumption that the ability to email a user's password means the passwords are in plain text. There is such as thing as secure two-way encryption. Using symmetric encryption to encrypt passwords in a database would not be smart. Where are you going to keep the key? If the hacker gets the dbase, then they've probably got the key as well. There's no point in dancing around this issue. The only acceptable way to store passwords is a slow one way hash. If you get your password in plaintext, the security is lax. The second link is about a security problem in ruby on rails. Unfortunately ruby doesn't have proper utf-8 support so ruby on rails needs to monkey-patch the ruby string classes to provide proper support. It is unsurprising that there was a bug in this patching. This is a framework issue that has nothing to do with 37signal's security practices. Hindsight is 20/20. Frameworks always end up with security issues. At least you can see that it's been fixed for some time. The bad part about the second link isn't that the vulnerability happened, its that 37signals had no infrastructure in place for security researchers to report problems. Of course vulnerabilities are going to happen. It's a certainty. But you need to have a system in place for the good guys to report problems. I'm not aware of any informed person that criticized them for the actual vulnerability. If you read the link I provided, you'll notice this quote: "It is literally the-simplest-thing-not-to-fuck-up. Nobody's asking you not to have security vulnerabilities. In fact: nobody's even asking you to fix vulnerabilities. We just need a reliable way to communicate with you about them." They've got a communication channel now: http://37signals.com/security-response http://37signals.com/security-response.

by tree5 17y ago

tsally 17y ago

It happened (storing in plaintext, not losing the actual passwords): http://www.jgc.org/blog/2009/05/can-you-trust-37signals-with-your.html http://www.jgc.org/blog/2009/05/can-you-trust-37signals-with... We've covered 37signals poor approach to security before: http://news.ycombinator.com/item?id=804257 http://news.ycombinator.com/item?id=804257 It's my understanding that they've since reformed. I'd be interested in what books you think they've written that provide credible security advice. Blind "fanboyism" (if I may invent a word) is a bad thing.

tree5 17y ago
"Agile Web Development With Rails", Chapter 11, Administration
- tsally 17y ago
  Here's the sample code they give in that chapter: def self.encrypted_password(password, salt) string_to_hash = password + "wibble" + salt # 'wibble' makes it harder to guess Digest::SHA1.hexdigest(string_to_hash) end They are using SHA1 with a salt, the exact method that security experts recommend against when storing passwords: http://news.ycombinator.com/item?id=995645 http://news.ycombinator.com/item?id=995645. And obviously they didn't even use this insecure method internally. EDIT: tptacek makes a good point. I haven't quite been fair. 37signals did what most companies never do when confronted with a security issue: they quickly acknowledged the problem, fixed it based on the suggestions of the security researchers, and moved on.
  - tptacek 17y ago
    You're right. Just give them credit for taking their lumps, apologizing, and getting religion.
cloudkj 17y ago
I'm guessing tree5 is talking about "Agile Web Development With Rails," in which the authors do give examples of creating hashed passwords with a unique salt and running a SHA1 digest. The book also talks about preventing plain text passwords from showing up in log files from form submissions. From what I understand however, AWDWR is only tangentially related to 37signals.
tptacek 17y ago
There is a difference between storing plaintext passwords and actually losing them, and as much as I hate to give someone a pass on insecure password storage (it is, apparently, all I ever talk about here), you have to be intellectually honest. And, like I say every time this comes up, FedEx and several banks also store plaintext passwords. 37signals no longer stores easily attacked passwords.
- tsally 17y ago
  There is a difference between storing plaintext passwords and actually losing them, and as much as I hate to give someone a pass on insecure password storage (it is, apparently, all I ever talk about here), you have to be intellectually honest. I was intellectually honest. I explicitly said they didn't actually lose them. 37signals no longer stores easily attacked passwords. I was under the impression that this was true as well. However I just checked and I got my Backpack password emailed to me in plain text. So at least the Backpack application is still incorrect.
  - tptacek 17y ago
    Either they haven't gotten to you in the rollout yet, or they aren't doing Backpack (which would surprise me). The "honesty" comment wasn't directed to you, but it's obvious why you would think it was. Sorry.
    - tsally 17y ago
      The "honesty" comment wasn't directed to you, but it's obvious why you would think it was. Sorry. Given your history of quality and logical posts, I pretty much knew the comment wasn't directed towards me. I just wanted to go on record to be sure. I'm sorry as well, I should have just let it fly. Either they haven't gotten to you in the rollout yet, or they aren't doing Backpack (which would surprise me). They're launching unified accounts soon for all services (you have to pick a new user name and password if I remember correctly). Perhaps this is when they'll roll out the password security? Seems like a logical time to me.
epochwolf 17y ago
Both of those links are not proof of any lax security at 37signals. The first link makes the assumption that the ability to email a user's password means the passwords are in plain text. There is such as thing as secure two-way encryption. (Granted, if the hacker gets the encryption key, you're hosed.) You can read more about that in the comments on that blog. [ignore] The second link is about a security problem in ruby on rails. Unfortunately ruby doesn't have proper utf-8 support so ruby on rails needs to monkey-patch the ruby string classes to provide proper support. It is unsurprising that there was a bug in this patching. This is a framework issue that has nothing to do with 37signal's security practices. Hindsight is 20/20. Frameworks always end up with security issues. At least you can see that it's been fixed for some time. Okay, issue was with the lack of a secure channel. Point taken. That was a mistake. [Removed section on procedures and mistakes, as non-relavent.] (Disclosure: I use ruby on rails)
- tsally 17y ago
  The first link makes the assumption that the ability to email a user's password means the passwords are in plain text. There is such as thing as secure two-way encryption. Using symmetric encryption to encrypt passwords in a database would not be smart. Where are you going to keep the key? If the hacker gets the dbase, then they've probably got the key as well. There's no point in dancing around this issue. The only acceptable way to store passwords is a slow one way hash. If you get your password in plaintext, the security is lax. The second link is about a security problem in ruby on rails. Unfortunately ruby doesn't have proper utf-8 support so ruby on rails needs to monkey-patch the ruby string classes to provide proper support. It is unsurprising that there was a bug in this patching. This is a framework issue that has nothing to do with 37signal's security practices. Hindsight is 20/20. Frameworks always end up with security issues. At least you can see that it's been fixed for some time. The bad part about the second link isn't that the vulnerability happened, its that 37signals had no infrastructure in place for security researchers to report problems. Of course vulnerabilities are going to happen. It's a certainty. But you need to have a system in place for the good guys to report problems. I'm not aware of any informed person that criticized them for the actual vulnerability. If you read the link I provided, you'll notice this quote: "It is literally the-simplest-thing-not-to-fuck-up. Nobody's asking you not to have security vulnerabilities. In fact: nobody's even asking you to fix vulnerabilities. We just need a reliable way to communicate with you about them." They've got a communication channel now: http://37signals.com/security-response http://37signals.com/security-response.