Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!
-
@fbmac said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
Another story
A co-worker was very proud showing the login form he did, where the hash was calculated client side and sent to the server, and there was no salt.
I don't remember if I managed to convince him that in his system an attacker that obtained the hash could login to the system, making the hash effectively the password, and it was no better than storing passwords as plain text.
I've been there too... and it communicated over plain HTTP, and it was called 'secure password transfer'. Open sores though.
-
@error said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
I informed management of what I found and attempted to communicate what a terrible idea it was (including possible legal liability), but took no action.
Wow. You're lucky they didn't try to fire you and have you arrested for hacking.
-
@error I'll on-up that: Everyone in the company (hopefully due to some accidental misconfiguration in Active Directory) who had a RSA token (to access a Citrix gateway so you could RDP into your machine) was given Local Administrator privileges (because Administrators accounts are always allowed to RDP into their own machine by default).
Additionally, out Lotus Notes configuration and mail files were configured to go into the root under
C:\Notes
.Guess what that allowed us to do?
If you guessed all sorts of things, including (but not limited to!) spoof email insertion into the CEO's mailbox, you'd be right!
Who knows how long this persisted before I discovered it, but it was patched in only three weeks!
-
@error said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
Almost. Generally you want to use an expensive algorithm like bcrypt. That one can scale the cost of calculating the hash arbitrarily (so as computational power increases, so does the cost of computing hashes).
Edit: bcrypt also has the advantage of not doing it yourself. Because implementing security practices is super easy to fuck up, and it's not obvious when you've messed something up.Php goes even further nowadays and advocates to use built-in functions
password_hash
andpassword_verify
which more or less do everything, and extends the advice of not doing it yourself to the salt generation, password verification (apparently with risk of timing attacks), keeping the bcrypt cost parameter up-to-date, and so on.
-
@Grunnen How long will it be before we have
password_hash_real
andpassword_verify_real
?
-
@tufty Haha, but do you really think that most developers do it better? Thanks to this thread I have reviewed the login code from my personal website:
public function CheckPassword(mod_User $user, $password) { return crypt($password, $user->GetPasshash()) == $user->GetPasshash(); } public function SetPassword(mod_User $user, $password) { $salt = ''; $saltrange = array_merge(range('a', 'z'), range('A' ,'Z'), range('0', '9')); for($i = 0; $i < 22; $i++) { $salt .= $saltrange[mt_rand(0, count($saltrange)-1)]; } $user->SetPasshash(crypt($password, sprintf('$2a$%02d$', self::pwd_costnr) . $salt)); }
I thought I put quite some research and thought into it when I wrote it four years ago. But still, there you have two or three security holes already: the salt is not generated with a proper random number generator, the password verification allows a timing attack, and the cryptographic algorithm isn't properly chosen/configured. Okay, for a personal home page these risks aren't that big. Still, if I change the code like so:
public function CheckPassword(mod_User $user, $password) { return password_verify($password, $user->GetPasshash()); } public function SetPassword(mod_User $user, $password) { $user->SetPasshash(password_hash($password, PASSWORD_DEFAULT)); }
then the likeliness of a mistake on my side is just about zero and the language/framework/library developers can change the implementation and can update the
PASSWORD_DEFAULT
option constant if necessary.
-
@Grunnen said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
do you really think that most developers do it better
Developers who develop in PHP, or the developers who develop PHP?
Actually, it doesn't matter. The answer is "no".
-
@tufty Using another language than php doesn't make you a cryptography expert
-
@Grunnen Of course not. But it does mean you won't be using PHP's
password_crypt_really_real_this_time
.Almost all developers are far worse at security than they think. I include myself in this group. I also include the developers of the PHP language itself, who have, let's face it, a pretty awful track record. They're almost certainly far worse at security than even I think.
Is
password_crypt
better than making developers roll their own? Almost certainly, and if it turns out their "copied from John the Ripper" code turns out to have big fuckoff security flaws in it, it can be fixed without modifying external developers' code.But it'll probably be fixed with
password_crypt_really_secure_this_time_we_promise
.
-
@tufty I'll grant you PHP certain,y used to have a terrible track record with "helpful features" that were "beginner friendly" like register_globals and magic quotes. The dev team learned from their mistakes.
PHP has improved quite significantly since then, though. It's not perfect, though, and made worse by shitty hosting companies that don't upgrade. But the language is improving by leaps and bounds.
-
@Polygeekery said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
Of course, then you end up having to field questions like:
"It looks good, but nothing is in English. I can't read anything on the site. It's all in French or Italian or something..."
"That's placeholder text. It is called Lorem Ipsum."Never use Lorem Ipsum, I always for dev purposes get similar content that is likely to be on a page i.e. when doing a horse racing widget I used out of date races and odds and news. Because otherwise you won't know how real text will sit on the page. Obviously this is purged (before production).
BTW this maybe considered a weird hack, but it works nicely:
-
@lucas1 said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
Never use Lorem Ipsum, I always for dev purposes get similar content that is likely to be on a page i.e. when doing a horse racing widget I used out of date races and odds and news. Because otherwise you won't know how real text will sit on the page. Obviously this is purged (before production).
We don't do much web development anymore unless it is an internal project. The ones that we did were usually marketing sites, so really we were just fitting blocks of text and not dynamic data.
For internal purposes we just copy the working database to make mock-ups and then we having a staging/sandbox area for finishing up. Or, honestly, if we could tolerate a little bit of downtime, etc...
-
@Polygeekery said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
The ones that we did were usually marketing sites
I take that back. We did do a fair chunk of Django work years ago and some Rails work, developing internal applications for others.
In those cases, we would just throw in enough rubbish data to make it look OK. Or, we would grab a copy of whatever database we were transitioning from and work out the migration first and then work from a copy of that data. Then, at transition time, we already had everything worked out and we just needed to do an up to date migration and we were done.
-
I mainly work with CMS products these days (even though it is very boring it pays well) so you end up building everything arount the content.
-
@tufty said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
I also include the developers of the PHP language itself, who have, let's face it, a pretty awful track record.
This never stops being funny...
http://use.perl.org/use.perl.org/_Aristotle/journal/33448.html
-
@PJH said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
This never stops being funny...
Another from my RSS feed today...
-
@PJH from the linked article:
Of course, that doesn't mean the PHP source code is easy to follow - it is written in C and 80% of the code is basically a hodgepodge of horribleness that exists to deal with cross-platform and third-party library integration issues and various bits of ancient cruft that have stuck around from the very beginning of the language.
This made me laugh, I'm a bad person ?
On the other side, I do not use PHP, so...
-
@cabrito no, it makes you completely normal.
Even diehard PHPers like me find it funny, if a bit sad.
-
Right. So if meanwhile even shitty PHP encourages to use the standard library for creating and checking passwords, instead of messing around on your own, this should be even more so true for any 'real' programming language.
-
Is it too late to say scrumbags?
-
@dse It most certainly is not too late to say scrumbags.
scrumbags.
-
Wow, now I really do feel old.
I've not hung around here for a while. When I was a regular, VB was the language being bashed.
-
@oldcoder like vb, php is just the most popular language now, and it's popular because it's good, and cost almost nothing to host.
-
@fbmac said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
good
(CBA to find the TDWTFified version...)
-
@cabrito said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
@PJH from the linked article:
Of course, that doesn't mean the PHP source code is easy to follow - it is written in C and 80% of the code is basically a hodgepodge of horribleness that exists to deal with cross-platform and third-party library integration issues and various bits of ancient cruft that have stuck around from the very beginning of the language.
This made me laugh, I'm a bad person ?
On the other side, I do not use PHP, so...I've had to dig into the PHP source to find out how its soap server works. It's not pretty, and at the same time may be one of its saner components.
-
@PleegWat said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
PHP
@PleegWat said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
soap
doNOTWANTATALLHOLYSHITWHY
-
@sloosecannon said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
doNOTWANTATALLHOLYSHITWHY
Amen brother.
-
I hate dealing with SOAP, it even sucks when using Visual Studio.
-
@lucas1 We handle both client and server side, on different platforms. The SOAP requirement came from on high. Both sides are nasty in incompatible ways so it's a devil to get working. I've mostly done the PHP/server end, and I understand the client end (in java) is worse, as they can't use autogenerated stuff because that breaks if we need to modify the wsdl in a newer version.
-
@PleegWat said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
@lucas1 We handle both client and server side, on different platforms. The SOAP requirement came from on high. Both sides are nasty in incompatible ways so it's a devil to get working. I've mostly done the PHP/server end, and I understand the client end (in java) is worse, as they can't use autogenerated stuff because that breaks if we need to modify the wsdl in a newer version.
Jeeeeeeeeezus.
Because the most logical communication path between PHP and Java is SOAP.
-
@sloosecannon said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
Because the most logical communication path between PHP and Java is SOAP.
Where did I say it was logical? I said it came from on high. I believe REST+JSON is legal for new connections nowadays but we're stuck with SOAP.
-
@PleegWat said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
@sloosecannon said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
Because the most logical communication path between PHP and Java is SOAP.
Where did I say it was logical? I said it came from on high. I believe REST+JSON is legal for new connections nowadays but we're stuck with SOAP.
Oh you didn't. In fact, I think you said the contrary (from on high). I'm just ridiculing those on high. Because they probably were high.
-
@sloosecannon said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
@PleegWat said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
@sloosecannon said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
Because the most logical communication path between PHP and Java is SOAP.
Where did I say it was logical? I said it came from on high. I believe REST+JSON is legal for new connections nowadays but we're stuck with SOAP.
Oh you didn't. In fact, I think you said the contrary (from on high). I'm just ridiculing those on high. Because they probably were high.
I think at the time a remote communication was always between two JAVA nodes. Our PHP comes out of an acquisition, it does not otherwise exist in this company.
-
@Vaire said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
What would you use instead, in that scenario?
Tricky. What I did when I hit it was put an in-memory cache in front that cached the values sent by the client over the wire so that a repeat lookup (the normal case) would be fast. The cache was only created after a successful authentication, and was purged whenever the user changed their password or after 10 minutes (I think that's what the timeout was).
I don't particularly like that solution as it is keeping a security token around, but it was at least safe from external attack and only accelerates correct logins (which are the ones it is usually OK to make fast) whereas bad logins bear the bcrypt cost every time. Doing anything “better” involves sessions, and they have different challenges, notably making writing clients a lot more complex (something which I didn't want for other reasons that are unimportant now).