Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Update on Tuts+ Premium Security Breach

notes.envato.com

Post reply on HN
Print view View original

11–20 of 25 posts

Re: Update on Tuts+ Premium Security Breach

#11

Post by huxley »

16s wrote: post #7
moonboots wrote: post #4

NetTuts needs to mention which key derivation function they are using so the community can verify they didn't fuck up again. I would also recommend that they use this opporunity to teach their web developing users about proper password storage, but after reading their php hashing tutorial[1], I think it's best if their users look elsewhere. The tutorial eventually recommends bcrypt after listing multiple unsafe solut…

There's no real way to 'verify' this. They would have to provide the source code in its entirety and several card-carrying, certified cryptanalysts/cryptographers would have to vet it and then publicly approve of it. That will never happen. Users have to have some level of trust. Like everything else in life.

If they use a well-maintained standard library which uses a modern cryptographic hashing function, then I think they earn that trust.

There is no real disadvantage to saying which one and a lot of trust to regain.

Re: Update on Tuts+ Premium Security Breach

#12

Post by kadabra9 »

this wasn’t a failure of, or a reflection of, the professionalism and integrity of our development or Tuts+ teams.

How is it not? There is NO excuse for storing passwords in plaintext, on any production site. From what I've read, they had this system in place for a while, and planned "to get around to" switching to a more secure password storage method eventually.

Sadly, it looks like a massive security breach was the catalyst they needed to realize that you can't put issues like user password security on the backburner.

Now, we get the same reactive "we're sorry, we should have known better" from the tuts+ leadership, and a promise that things will be better in the future. Why does it always take a humiliating security breach for companies like this to realize just how important user security, and by extension, your users' trust, really is?

Re: Update on Tuts+ Premium Security Breach

#13

Post by huxley »

biot wrote: post #9
rpsw wrote: post #6

Earlier quoted context omitted.

In of itself, the statement isn't incorrect though is it? Are you sighing because you believe the statement implies a poor hash function will be chosen?

It's not incorrect, but it's somewhat telling that such a massive vulnerability that they were fully aware of "has been running for a long time" and rather than fork over $179.95 for the new version of aMember which would have completely fixed the vulnerability, they chose instead to let the vulnerability remain while they embarked on a greenfield project to rewrite their membership system from scratch. This rewrite…

Do you happen to know what the new version of aMember uses for password hashing?

I saw some mentions of MD5 in forums and some handwaving about how other scripts use custom password security, but nothing definitive.

We looked at aMember for a project several years ago, before we switched to Django for all our development so I haven't kept up on what is available security-wise on PHP.

Re: Update on Tuts+ Premium Security Breach

#15

Post by SoftwareMaven »

kadabra9 wrote: post #12

this wasn’t a failure of, or a reflection of, the professionalism and integrity of our development or Tuts+ teams. How is it not? There is NO excuse for storing passwords in plaintext, on any production site. From what I've read, they had this system in place for a while, and planned "to get around to" switching to a more secure password storage method eventually. Sadly, it looks like a massive security breach was th…

If the team came to him and said, "Mr CEO, we have this glaring security problem we want to fix", and then Mr CEO replied, "We have other, higher priority things to work on right now, so no, please do not fix that."

We already know they didn't write it, but we don't have enough other information to make any other judgements (and the blog post at least implies the above may have happened).

Re: Update on Tuts+ Premium Security Breach

#16

Post by zhoutong »

> I should also note that aMember had in the meantime released an upgrade to their service which deals with the issue, though an upgrade with our heavily modified system was a significant endeavour.

In the previous blog post:

> Our current Tuts+ Premium app makes use of a third party plugin that unfortunately stores passwords in cleartext (i.e. unencrypted).

The previous post sounded like they were too lazy to change the authentication system to a more secure one. But they now said they had a "heavily modified system".

> I’d like to take a moment to be clear that this wasn’t a failure of, or a reflection of, the professionalism and integrity of our development or Tuts+ teams.

I think any capable developer should find it easier to add BCrypt into the password field than the heavy modifications. Once they are familiar enough with the plugin (for heavy modifications), it shouldn't take more than a day to make it secure.

Re: Update on Tuts+ Premium Security Breach

#17

Post by biot »

huxley wrote: post #13
biot wrote: post #9

Earlier quoted context omitted.

It's not incorrect, but it's somewhat telling that such a massive vulnerability that they were fully aware of "has been running for a long time" and rather than fork over $179.95 for the new version of aMember which would have completely fixed the vulnerability, they chose instead to let the vulnerability remain while they embarked on a greenfield project to rewrite their membership system from scratch. This rewrite…

Do you happen to know what the new version of aMember uses for password hashing? I saw some mentions of MD5 in forums and some handwaving about how other scripts use custom password security, but nothing definitive. We looked at aMember for a project several years ago, before we switched to Django for all our development so I haven't kept up on what is available security-wise on PHP.

The Envato post says the passwords will be individually hashed and salted. The aMember forum has a few more details:

4.1.3 release: http://www.amember.com/forum/threads/amember-pro-version-4-1... states "Removed user.pass variable from email templates. Plain text password in not available anymore."

4.1.6 release: http://www.amember.com/forum/threads/amember-pro-version-4-1... states "Closes #448 - and do not save md5 passwords at all".

User issue: http://www.amember.com/forum/threads/urgent-amember-v4-1-12-... "Unfortunately, in the email received by customers, the password comes out encrypted like $P$BkTNDykCkTfsOqHwsV4TT2/"

The hash format indicates it's using PHPass: http://cvsweb.openwall.com/cgi/cvsweb.cgi/projects/phpass/Pa... which is based on MD5, but with the log of the number of rounds indicated by the first character after the $P$ prefix. In the forum example, it's "B" which is 11 making it 2^11 rounds. The remainder is an 8 character salt plus checksum. PHPass is authored by "Solar Designer" or Alexander Peslyak, also the author of John the Ripper and respected in the security community: http://en.wikipedia.org/wiki/Alexander_Peslyak so is likely pretty solid.

Re: Update on Tuts+ Premium Security Breach

#18

Post by tptacek »

biot wrote: post #17
huxley wrote: post #13

Earlier quoted context omitted.

Do you happen to know what the new version of aMember uses for password hashing? I saw some mentions of MD5 in forums and some handwaving about how other scripts use custom password security, but nothing definitive. We looked at aMember for a project several years ago, before we switched to Django for all our development so I haven't kept up on what is available security-wise on PHP.

The Envato post says the passwords will be individually hashed and salted. The aMember forum has a few more details: 4.1.3 release: http://www.amember.com/forum/threads/amember-pro-version-4-1... states "Removed user.pass variable from email templates. Plain text password in not available anymore." 4.1.6 release: http://www.amember.com/forum/threads/amember-pro-version-4-1... states "Closes #448 - and do not save md5…

Solar Designer is great. Here's what his PHPass page says:

The preferred (most secure) hashing method supported by phpass is the OpenBSD-style Blowfish-based bcrypt, also supported with our public domain crypt_blowfish package (for C applications), and known in PHP as CRYPT_BLOWFISH, with a fallback to BSDI-style extended DES-based hashes, known in PHP as CRYPT_EXT_DES, and a last resort fallback to MD5-based salted and variable iteration count password hashes implemented in phpass itself (also referred to as portable hashes).

To ensure that the fallbacks will never occur, PHP 5.3.0+ or the Suhosin patch may be used. PHP 5.3.0+ and Suhosin integrate crypt_blowfish into the PHP interpreter such that bcrypt is available for use by PHP scripts even if the host system lacks support for it.

Re: Update on Tuts+ Premium Security Breach

#19

Post by wglb »

rpsw wrote: post #6
tptacek wrote: post #2

I anticipate the service will be coming back online in the next 24 hours, with all passwords reset, hashed and individually salted (a best practice) Sigh.

In of itself, the statement isn't incorrect though is it? Are you sighing because you believe the statement implies a poor hash function will be chosen?

Individually salted passwords will store the salt right next to the password and hash in the database. Then, when the database gets downloaded (which is presumably what happened), then the attacker can buy one of those new fangled Radeon cards and unsalt the stored hash and try passwords at the rate of hundreds of millions per second. Salting will not measurably slow this process down.

Salting prevents effective use of rainbow tables. It does not protect against brute force attacks, which are now incredibly cheap.

Individually salting passwords was best practice internet eons ago, not now.

Best practice is to use a work-adjustable scheme such as provided by bcrypt.

Re: Update on Tuts+ Premium Security Breach

#20

Post by rpsw »

wglb wrote: post #19
rpsw wrote: post #6

Earlier quoted context omitted.

In of itself, the statement isn't incorrect though is it? Are you sighing because you believe the statement implies a poor hash function will be chosen?

Individually salted passwords will store the salt right next to the password and hash in the database. Then, when the database gets downloaded (which is presumably what happened), then the attacker can buy one of those new fangled Radeon cards and unsalt the stored hash and try passwords at the rate of hundreds of millions per second. Salting will not measurably slow this process down. Salting prevents effective use…

But salting is also fundamental in bcrypt. Using an function with adjustable work factor doesn't mean salting is not a good idea. Any cryptologic hash people will mention as a best practice will generally have the notion of salting built-in.
Post reply on HN