Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!
-
I have posted this to the Scrum.org forum and it's in moderation. I wonder if they'll approve it.
I just received an email about the Scrum.org data breach...
"...we have determined that user’s names, email addresses, encrypted passwords, the password decryption key, and completed certifications and their associated test scores may have been compromised..."
Wait, what?
What is the point of storing encrypted data along with the decryption key? That is worthy of a thedailywtf.com submission!
But what I find sinister is that you store our passwords using reversible encryption at all. What possible reason do you have to decrypt our passwords? They are ours, not yours! I cannot think of any (innocent) scenario in which you would need them in the clear.
You have betrayed our trust by storing our email addresses, usernames and passwords insecurely. This is a problem that has impact FAR beyond revealing our test scores.
Please explain how this could have happened.
-
All data may have been encrypted, pass hashed as appropriate (and then encrypted along with the other data).
It's unlikely, but it could happen.
-
@swayde Then why scare users by calling it a "password decryption key"?
-
@oldcoder said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
They are ours, not yours! I cannot think of any (innocent) scenario in which you would need them in the clear.
Maybe they use the decryption key when they send an "I forgot my password?" e-mail?
-
@oldcoder said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
@swayde Then why scare users by calling it a "password decryption key"?
I was playing the 👿 's avocado.
With 99% certainty they're as dimwitted as it sounds.
-
@AlexMedia I haven't seen an "I forgot my password" feature that actually sends your password for a very very long time (probably since I was at Uni).
That feature should give you a time restricted option to set a new password but never tell you the forgotten one. That would be way too easy to exploit!
-
@oldcoder said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
I haven't seen an "I forgot my password" feature that actually sends your password for a very very long time
Cloud9, a hipster online IDE. Plaintext passwords, plaintext passwords everywhere.
Hell, that's the thing that pushed me to finally start using a password manager, so thanks, I guess.
-
@Onyx said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
@oldcoder said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
I haven't seen an "I forgot my password" feature that actually sends your password for a very very long time
Cloud9, a hipster online IDE. Plaintext passwords, plaintext passwords everywhere.
Hell, that's the thing that pushed me to finally start using a password manager, so thanks, I guess.
What's the benefit over any of the local IDEs?
-
@Dreikin It's more that the project is being hosted somewhere easily accessible and easy to set up for many common uses (there are pre-built VMs WordPress, NodeJS, etc.). Github integration works great as well.
Also, it's nice to have the ability of someone connecting to the session as well, the editor is fully collaborative. If it's open source and you don't mind it being public it's also free.
The editor itself is pretty much comparable to Sublime Text, not much more or less (well, except for plugins) there, really.
-
@Dreikin What sold me on it was the one-click temporary hosting. If you set up a run configuration, you can click the play button and it'll give you a link to port 80 of that VM, which is of course public so you can share it around and get feedback before going live. I use that as a dev server sometimes :)
-
@Yamikuronue said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
@Dreikin What sold me on it was the one-click temporary hosting. If you set up a run configuration, you can click the play button and it'll give you a link to port 80 of that VM, which is of course public so you can share it around and get feedback before going live. I use that as a dev server sometimes :)
That's pretty neat. Are they available under the free tier?
-
@Dreikin Yeah, it comes standard. I haven't upgraded to a paid tier at all. The URL ends up being something like
https://[workspacename]-[username].c9users.io/
and it goes away when they suspend your VM (which they do for the free tier when you don't use it for a while)
-
@oldcoder said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
I haven't seen an "I forgot my password" feature that actually sends your password for a very very long time
A system I have to use at work sends a "You have successfully changed your password to Hunter2" email
-
@oldcoder said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
I haven't seen an "I forgot my password" feature that actually sends your password for a very very long time (probably since I was at Uni).
That feature should give you a time restricted option to set a new password but never tell you the forgotten one. That would be way too easy to exploit!You obviously don't have to deal with government websites. Our state websites that are used to access and pay payroll and sales taxes both will send you your password instead of a reset link.
True story. I wish I were joking.
-
@Dreikin said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
What's the benefit over any of the local IDEs?
For working on *nix stack stuff on Windows, it is amazing. Also, the fact that your web server is open to the public works really well for letting the client see what you are working on as you are working on it so you can get their feedback without any odd setup required on your localhost.
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."
-
@Polygeekery said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
"That's placeholder text. It is called Lorem Ipsum."
Take that down immediate before somebody notices you're infringing on their copyright.
-
@Jaloopa said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
A system I have to use at work sends a "You have successfully changed your password to Hunter2" email
@Polygeekery said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
You obviously don't have to deal with government websites. Our state websites that are used to access and pay payroll and sales taxes both will send you your password instead of a reset link.
True story. I wish I were joking.
-
I wonder if the email was written by a non-techie and "decryption key" actually means "salt."
-
Well they still haven't replied to me or approved my post, but given the number of articles and comments that have shown up online lambasting them for this it's not really surprising.
It seems the passwords might have been salted though - if so then it was a very clumsy initial report email.
-
@oldcoder salted passwords.......
but they were stored encrypted! with a decryption key!
salting is useless if you can decrypt the password!
-
@accalia said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
but they were stored encrypted! with a decryption key!
Unless whoever wrote the email didn't understand the difference between encryption and hashing, salts and keys
-
@oldcoder said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
I have posted this to the Scrum.org forum and it's in moderation. I wonder if they'll approve it.
I think it's very unlikely, you didn't put it in the required format.
User story time!
-
As a user I don't want my password stolen by nasty evil crackers.
-
As a user I want to be sent a new password when I click the Reset password link in my email, I never want to see my previous password ever again. The fact I forgot means I'll likely forget the second time.
-
As a sysop, I don't want to be caught with my pants down when we get a visit from ol' Bobby Rainbowtables.
-
As an evangelist, I should have known better.
-
-
@Jaloopa said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
@accalia said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
but they were stored encrypted! with a decryption key!
Unless whoever wrote the email didn't understand the difference between encryption and hashing, salts and keys
Indeed, that was my first thought, that someone misinterpreted the salt as a "decryption key".
-
@oldcoder Did the hackers also steal your closing italics tag?
-
Whatever they did, it strongly hints that they rolled something themselves instead of using established software (say bcrypt)
-
@Polygeekery said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
You obviously don't have to deal with government websites. Our state websites that are used to access and pay payroll and sales taxes both will send you your password instead of a reset link.
True story. I wish I were joking.
I've done a few websites that the "user" side insist we have feature to send password back in "Forgot password" link instead of just send a password reset link.
Spent half days trying to persuade them this is bad but no use.
-
From here (my emphasis) :
In addition to closing the vulnerability as directed by our vendor and deleting the invalid administrator account, we have reset the passwords of all Scrum.org accounts. To continue accessing your account, you will be required to set a new password at your next login. This summer, we are also moving to a new software vendor that provides greater password security.
So my guess would be that yes, they were storing passwords encrypted rather than hashed, and storing the [en|de]cryption keys as well.
Given that they are still running with the same system (modulo one security hole plugged) they've also got their heads rammed firmly up their fundaments.
-
@accalia said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
@oldcoder salted passwords.......
but they were stored encrypted! with a decryption key!
salting is useless if you can decrypt the password!
Yeah sorry, a rushed post at work.
I meant that since the passwords were apparently salted they were probably hashed not encrypted, and that the email from scrum.org was just incorrectly worded.I've just got a reply from them though...
The Scrum.org platform used a commercially available software package to manage user’s passwords and access to a user’s information. During our investigation into this security incident, we have been made aware of the security capabilities of this software package, which included the use of encryption keys and salted passwords instead of hash functions to store the password. We have implemented greater security protections as a result of the applied patches and are working to include the use of one-way hash functions to store the password. However, the changes to implement one-way hashing requires changes to our interface, and we are diligently working to roll out our use of the new capability as soon as possible. Following the incident, we invalidated all passwords to protect them, hence requiring a new password be created on your next login.
We do not know if any of this was taken, but are treating it as it was to ensure your account remains protected.
We apologize for any inconvenience this may have caused you and please let us know if you have any further questions.
Obviously I have asked what the product was but I'm guessing they won't say. I agree with others here that it might have been a home grown solution, possibly coded by someone's kid. This doesn't sound likely if it was an off-the-shelf solution: "We have implemented greater security protections as a result of the applied patches and are working to include the use of one-way hash functions to store the password."
I can't think why they would want to protect a commercial vendor. I guess it's possible they are protecting themselves by not revealing their tech stack.
-
@oldcoder said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
I can't think why they would want to protect a commercial vendor.
Loads of reasons:
They misconfigured the software
The vendor has threatened to sue( for say defamation / lack of ice-cream)
They're pirating the product
They're lying, and it's something like .Net mvc that's the commercially available tool.
They're clueless as fuck
It'll look unprofessional
It's unproductive
It's part of a settlement with the vendor
-
@swayde said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
They're clueless as fuck
I'm gonna pick that option, please.
-
@oldcoder said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
encryption keys and salted passwords
What does that even mean? They added extra plain text padding to prevent guessing length?
-
Another update - the evil software they blame is DotNetNuke. Apparently there was a vulnerability but they weren't notified until it was too late.
I found this: http://stackoverflow.com/questions/12418932/how-does-dotnetnuke-hash-its-passwords
Looks like hash + salt indeed.
-
@oldcoder said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
Another update - the evil software they blame is DotNetNuke. Apparently there was a vulnerability but they weren't notified until it was too late.
I found this: http://stackoverflow.com/questions/12418932/how-does-dotnetnuke-hash-its-passwords
Looks like hash + salt indeed.
Oh, we're talking about DotNetNuke? That's the worst pile of shit I've ever had the misfortune of working with, and I've worked with major WTFs.
I can absolutely confirm the passwords are decryptable (by default, at least when I used it). I wrote a utility that decrypts them. I worked for a web agency, and our clients would sometimes change the admin password (locking us out), and the utility was helpful there.
-
@boomzilla said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
@oldcoder said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
encryption keys and salted passwords
What does that even mean? They added extra plain text padding to prevent guessing length?
It is just as stupid as it sounds, but using a salt with encryption (instead of a hash) still helps with the same problem: dictionary attacks. An attacker, not knowing the encryption key, can still guess at 1000s of passwords at once if no salt was used. Also, (I may have been wearing a black hat at times with this data...) without guessing the password, you can often times tell if two users are the same person if their password hash/encrypted blob is the same.
Edit:
select passwordBlob, count(*) from users group by passwordBlob order by 2 desc
will quickly show you the blobs of the most common passwords.
Nowselect username, users.passwordBlob, Count from users inner join ( select passwordBlob, count(*) as Count from users group by passwordBlob ) counts on users.passwordBlob = counts.passwordBlob order by Count desc
And you know who shares the most common passwords. The mere fact that the password is so common means that it's probably something easy to guess. Now direct your attacks at the site; you don't know the hash/encryption algorithm that generated these blobs but you know it's something easy, and cracking it for one of them will give you access to all of those users. You can even try a different username with each password attempt, which could sidestep rate limiting.
Editedit: Once you've cracked the common/easy passwords, now you can launch a known plaintext attack on the remaining data.
-
@oldcoder said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
Another update - the evil software they blame is DotNetNuke.
Hahahahahahahaha
phpNuke was one of the commonly-used pieces of software (along with phpBB) that were the biggest contributors to PHP's reputation for being an insecure language. I'm not at all surprised that the people working on the .NET version suck just as much as they did 10 years ago.
-
@cheong said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
@Polygeekery said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
You obviously don't have to deal with government websites. Our state websites that are used to access and pay payroll and sales taxes both will send you your password instead of a reset link.
True story. I wish I were joking.
I've done a few websites that the "user" side insist we have feature to send password back in "Forgot password" link instead of just send a password reset link.
Spent half days trying to persuade them this is bad but no use.
I've had to do that, too. I just explain it to them a few times, state in no uncertain terms it's a bad idea and horrible security, then get them to sign a waiver of liability.
-
@oldcoder
just checking in here to make sure my best practices are up to date...
Last time I read the white papers of this subject, best practice was:
-1-way hash things like passwords
-use a random salt for each hash
-use a true random number generator (as best as can be used in language of choice) to generate the salt
-store the salt along with the passwords, to allow for comparison of input passwords
-thus rendering rainbow tables useless, while avoiding the issue of having a single salt stored somewhere which, if found, allows rainbow tables to work.My info up to date?
-
@Vaire said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
@oldcoder
just checking in here to make sure my best practices are up to date...
Last time I read the white papers of this subject, best practice was:
-1-way hash things like passwords
-use a random salt for each hash
-use a true random number generator (as best as can be used in language of choice) to generate the salt
-store the salt along with the passwords, to allow for comparison of input passwords
-thus rendering rainbow tables useless, while avoiding the issue of having a single salt stored somewhere which, if found, allows rainbow tables to work.My info up to date?
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.
-
@boomzilla said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
What does that even mean? They added extra plain text padding to prevent guessing length?
Requirement: All passwords must be 20 characters in length
Implementation: Zero-leftpad all passwords that are less than 20 characters
Sprint 1: Users are trying to enter passwords greater than 20 characters. Add regex to prevent this
Sprint 2: Users are complaining about long passwords being denied. Remove regex, add code to trim passwords greater than 20 characters
Sprint 3: Users disabled the Javascript trim. Investigate possibility of trimming passwords on the server
Sprint 4: Changed database so password field is only varchar(20)
Sprint 5: Users with long passwords reporting 500 error. Database is throwing error with password strings greater than 20 characters. Add regex back in
Sprint 6: Knowledge-share reveals that php code can trim strings to an arbitrary length. Hold Lunch-and-Learn to discuss
Sprint 7: Userbase has decreased, specifically amongst those with long passwords who can no longer log in. Added php 20-character trimming to appease them
Sprint 8: Also removed javascript regex that was preventing 20+ characters (code miss from Sprint 7)
Sprint 9: New bug. Users whose passwords start with 0 cannot log in. Investigate.
Sprint 10: Password checker retrieves password from DB, removes all left-padding 0s, then compares against user input. Was stripping out all 0s. Will have mindshare to discuss alternatives
Sprint 11: Added code that if someone enters 0 as the first character of password while logging in, will strip out all 0s except one zero from password prior to checking
Sprint 12: Users whose passwords start with 00 cannot log in. Will change padding character to a character no user will have in their password, like ~
Sprint 13: Users with ~ in their password cannot log in. Will add regex to prevent users from using ~ in password, and will force password reset for all users with ~
Sprint 14: Updated padding in database, replacing 0 padding with ~
Sprint 15: Users who had 0 at start of password cannot log in. The 0 at start of their password (non-pad) was accidentally changed to ~. Put message on homepage telling users to enter ~ instead of 0
Sprint 16: Users with 0 in password still cannot log in, because of regex added in Sprint 13. Will force those users to do a password reset
Sprint 17: Password reset page did not have new password rules. Users from Sprint 16 reset to old password, and now have 0 again and cannot log in. Will re-write 0 to ~ conversion script.
Sprint 18: Users with 0 in any part of their password cannot log in. Sprint 17 script replaced all zeros, not just padding zeros. Sending password reset email to those users to force password reset, then will re-run script
Sprint 19: Users who reset password to have ~ at the start cannot log in. Adding password rules to reset page, resending reset emails to effected users
Sprint 20: Password reset email was sent to all users instead of subset of users. Sending a follow up to only effected users, along with notation of why their password is non-conforming
Sprint 21: Error in JOIN statement used to build password reset mailburst from Sprint 20. Password reset email again sent to all users, with every user cc'd on every email. Sending apology.
Sprint 22: Email from Sprint 21 included plaintext password of every user. Forcing every user to do a password reset.
Sprint 23: Immediate stopwork on all projects. Company going through some stupid regulatory review by oppressive government. Sig Heil, mein furer lol
Sprint 24: Discussion of how to handle PR response to Sprint 23's meeting minutes being posted to company's blog with Nazi imagery.
-
@Lorne-Kates said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
@cheong said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
@Polygeekery said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
You obviously don't have to deal with government websites. Our state websites that are used to access and pay payroll and sales taxes both will send you your password instead of a reset link.
True story. I wish I were joking.
I've done a few websites that the "user" side insist we have feature to send password back in "Forgot password" link instead of just send a password reset link.
Spent half days trying to persuade them this is bad but no use.
I've had to do that, too. I just explain it to them a few times, state in no uncertain terms it's a bad idea and horrible security, then get them to sign a waiver of liability.
STORY TIME!
Yup, been there. Last place I worked at, it was hilarious. They were storing the password for their users for their open-internet accessible website in their database via a 1-way hash (obviously SOMEONE, at some time, knew what they were doing), BUT they were also storing the SAME GOD DAMN PASSWORD in CLEARTEXT in the SAME table, in the column right NEXT TO the hashed version.
When I discovered that and lurched gibbering into the office of the "managing developer" to ask about it (I had assumed it was either malicious, or somehow had been a Dev feature someone had forgotten to remove. I wanted to kill it ASAP for security reasons, and then force a password reset of all the users immediately), he stared at be blankly and told me that was a
"feature" they had always had built into the system.He explained (like I was the one who was confused), that the password in cleartext was not linked to anything in their application, and the only way to see it was to have access to the database itself. He said they used it to be able to tell their users what their passwords were, when they called in confused (their users were idiots -- involved with government, and generally older, that is all I will say).
I countered that it was WILDLY insecure, and that they were one data breach away from disaster. I stated in no uncertain terms that I WOULD NOT be responsible for it, and would require them to sign a release of liability if they insisted on keeping it that way. I then proposed that I kill that column, and force the password reset while at the same time implementing a "reset your password" function. They flatly refused.
It escalated into a meeting with myself, the manager, my HR rep, the senior HR rep, and the CEO of the company (wasn't a large company), and their lawyer. Where they, I shit you not, gave me my signed release of liability. I still can't believe they did it.
Needless to say, I started looking for my next gig while that was going on, and quit about a week later, and ran away like my ass was on fire. I would bet cash money that the column is still there, and easily accessible if anyone breaches them
-
@error said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
@Vaire said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
@oldcoder
just checking in here to make sure my best practices are up to date...
Last time I read the white papers of this subject, best practice was:
-1-way hash things like passwords
-use a random salt for each hash
-use a true random number generator (as best as can be used in language of choice) to generate the salt
-store the salt along with the passwords, to allow for comparison of input passwords
-thus rendering rainbow tables useless, while avoiding the issue of having a single salt stored somewhere which, if found, allows rainbow tables to work.My info up to date?
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 computing hashes).
Oh, yes, I forgot to mention that. Yes, I implement it with the bcrypt algorithm, specifically because it is expensive. Sorry, forgot to say that :(
-
One upvote is not enough. This is an Instant Classic.
-
@Vaire said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
Yes, I implement it with the bcrypt algorithm, specifically because it is expensive.
The only downside of using bcrypt is that it forces you to work with sessions, which in turn complicates the design of any API clients (since they have to deal with session refresh and shit like that).
-
@dkf said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
@Vaire said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
Yes, I implement it with the bcrypt algorithm, specifically because it is expensive.
The only downside of using bcrypt is that it forces you to work with sessions, which in turn complicates the design of any API clients (since they have to deal with session refresh and shit like that).
What would you use instead, in that scenario?
-
@Vaire I think I can top it.
I briefly did temp work for company. I found a Jet (i.e. Access) database file in the publicly accessible webroot containing all of their employee HR information. It had no password on it. All you needed was the URL.
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.
-
@error said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
@Vaire I think I can top it.
I briefly did temp work for company. I found a Jet (i.e. Access) database file in the publicly accessible webroot containing all of their employee HR information. It had no password on it. All you needed was the URL.
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.
I have said it before, and I will say it again, in an ideal world most people shouldn't be allowed anywhere near a computer without passing a basic knowledge test.
Instead, somehow, the people making the decisions about what is and isn't allowed tend to be the worst offenders [sigh]
-
@Vaire said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
I have said it before, and I will say it again, in an ideal world most people shouldn't be allowed anywhere near a computer without passing a basic knowledge test.
EVERYONE WHO WANTS TO SHOULD BE ABLE TO USE A COMPUTER AND YOU'RE A HORRIBLE PERSON FOR SAYING OTHERWISE! ( @blakeyrat , did I do that right?)
-
@antiquarian said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
@Vaire said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
I have said it before, and I will say it again, in an ideal world most people shouldn't be allowed anywhere near a computer without passing a basic knowledge test.
EVERYONE WHO WANTS TO SHOULD BE ABLE TO USE A COMPUTER AND YOU'RE A HORRIBLE PERSON FOR SAYING OTHERWISE! ( @blakeyrat , did I do that right?)
-
@Vaire said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
@antiquarian said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
@Vaire said in Scrum.org hacked and they stored encrypted passwords along with the key! WTF?!:
I have said it before, and I will say it again, in an ideal world most people shouldn't be allowed anywhere near a computer without passing a basic knowledge test.
EVERYONE WHO WANTS TO SHOULD BE ABLE TO USE A COMPUTER AND YOU'RE A HORRIBLE PERSON FOR SAYING OTHERWISE! ( @blakeyrat , did I do that right?)
that cat alway was creepy.....
-
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.