

Update on Tuts+ Premium Security Breach - jodi
http://notes.envato.com/news/tuts-premium-security-update/

======
tptacek
_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.

~~~
rpsw
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?

~~~
biot
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 would take an indeterminate
amount of time whereas they could have paid a paltry sum for the upgrade and
implemented it in less than 48 hours... as they just did.

I get that it's a prioritization issue. I've worked at places where legacy
software had poor security practices and it's often a judgment call as to the
risk of just letting it be vs. taking the time to rewrite whatever insecure
portion remained. Often the decision is to leave it when it's a one-off
project that will be shut down within a month, there is a limited attack
surface involved, and the data being stored insecurely is very low value. On
the other hand, security issues affecting the very core of a website (the
login system that 100% of a company's revenue depends on) should get addressed
as soon as the vulnerability is discovered. Additionally, they state that a
server was compromised... it's not clear whether this was a SQL injection
exploit that happened to display the users table remotely with no privilege
escalation, or whether the server was compromised via a poorly chosen SSH
password or similar and they may be dealing with a situation where rogue code
is still living on one or more servers.

~~~
huxley
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.

~~~
biot
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...](http://www.amember.com/forum/threads/amember-pro-
version-4-1-13-released.14476/) 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...](http://www.amember.com/forum/threads/amember-pro-
version-4-1-6-released.13699/) states "Closes #448 - and do not save md5
passwords at all".

User issue: [http://www.amember.com/forum/threads/urgent-
amember-v4-1-12-...](http://www.amember.com/forum/threads/urgent-
amember-v4-1-12-encrypted-password-is-sent.14511/) "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...](http://cvsweb.openwall.com/cgi/cvsweb.cgi/projects/phpass/PasswordHash.php?rev=1.8;content-
type=text%2Fplain) 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.

~~~
tptacek
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._

------
moonboots
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 solutions.
I understand that the author is trying to build up to the solution, but the
correct solution needs to be in the first paragraph. The incorrect solutions
need to be clearly flagged so a beginner skimming through doesn't see "md5"
and stop.

[1] [http://net.tutsplus.com/tutorials/php/understanding-hash-
fun...](http://net.tutsplus.com/tutorials/php/understanding-hash-functions-
and-keeping-passwords-safe/)

~~~
16s
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.

~~~
huxley
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.

------
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.

------
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?

~~~
SoftwareMaven
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).

------
laurencei
i fail to understand how any decent web company does not at the very minimum
hash passwords in this day and age. More importantly - a company who teaches
people coding and often runs 'best practices for XXXX courses' each month.

------
stevejabs
At least give it to them for being straight forward and honest. Yes, they
screwed up, but so have a lot of other companies that in my opinion hold much
much more sensitive data about me.

Not saying it's right for them to not take security as serious as they should
have, but unlike a lot of other companies, they disclosed it immediately, came
up with a game plan, apologized multiple times and are refunding users and
offering others free stuff.

I've changed my password on the other envato services I use as a just in case
and I still plan on using them in the future. They've always put together
great and in-depth tutorials and are a great resource for beginners, hackers
and experts.

