So, are we going to see extortion attempts like in the Ashley Madison leak? "We know you like Hello Kitty"...
This guy is worried. http://imgur.com/RNiWGSl
Database leak exposes 3.3M Hello Kitty fans
41–50 of 57 posts
Re: Database leak exposes 3.3M Hello Kitty fans
#42> unsalted SHA-1 password hashes Can we please get password storage built in to databases as a dedicated column type already? There are N-to-infinity crappy languages and CMS's out there, but only a handful of databases. It's becoming clear that widespread standard library support for decent password hashing just isn't enough to get people moved over.
Any good tutorial on how to deal with passwords? In a site of mine I generate a salt with UUIDv4 and generate a sha512 of the passsword+salt and store both the salt and hash. When the user authenticates I regenerate the hash and check. This is good, right? I still don't know how to deal with cookies/sessions though. And have no idea how basic http auth works. I'd search myself but I'm afraid to find a "bad" tutorial.
What you describe is easy to bruteforce using oclhashcat. Use scrypt or bcrypt or pbkdf2, in that order of preference.
Re: Database leak exposes 3.3M Hello Kitty fans
#43Earlier quoted context omitted.
The elephant in the room is what you return when you SELECT. My POV is you should be able to verify user sign-in with something like "SELECT COUNT(*) FROM users WHERE email = 'maaku@hellokitty.com' AND password='hunter2';", which has the added bonus of not informing the client whether the query failed because the user didn't exist, or because the password was wrong. Imho, all queries for the column content should sim…
Note that this approach can expose the user entered password in application debug logs, MySQL's slow queries log (if you're not using bind variables), etc.
That's true currently of any HTTP-level logs
Re: Database leak exposes 3.3M Hello Kitty fans
#44> unsalted SHA-1 password hashes Can we please get password storage built in to databases as a dedicated column type already? There are N-to-infinity crappy languages and CMS's out there, but only a handful of databases. It's becoming clear that widespread standard library support for decent password hashing just isn't enough to get people moved over.
Any good tutorial on how to deal with passwords? In a site of mine I generate a salt with UUIDv4 and generate a sha512 of the passsword+salt and store both the salt and hash. When the user authenticates I regenerate the hash and check. This is good, right? I still don't know how to deal with cookies/sessions though. And have no idea how basic http auth works. I'd search myself but I'm afraid to find a "bad" tutorial.
There's no way to beat around the bush: No, it is not good. It's better than a lot of sites, but it's still nowhere near good enough.
The key is speed: it's too fast. Far faster than you need it to be. Fast enough that attackers could attempt very large numbers of passwords per second.
What you want is something slow, to slow down the attackers.
Probably the most popular choice is bcrypt, and you can't go wrong making that decision. In some environments you may need something more standardised / accepted, in which case you want to look at PBDKF2. There's also scrypt, which is a bit stronger than bcrypt, but a bit newer.
_Any of these three are uncontroversial choices._ Using any of them is better than using just about anything else, and the gap between each of them is much smaller than the gulf between those three and schemes such as yours.
Once you've picked one you also need to tune it: make it as slow as you can bear. If your users won't be driven away by login taking a whole second, then make it take a whole second! The key is making it slow.
---
One broader piece of advice: Don't reinvent the wheel when it comes to security things. Passwords, sessions, and so on, you should be looking for well-supported, maintained, high-quality libraries that have been vetted for design and implementation mistakes. There's libraries out there to solve these problems, if you aren't a security expert you should be using them :)
Re: Database leak exposes 3.3M Hello Kitty fans
#45> unsalted SHA-1 password hashes Can we please get password storage built in to databases as a dedicated column type already? There are N-to-infinity crappy languages and CMS's out there, but only a handful of databases. It's becoming clear that widespread standard library support for decent password hashing just isn't enough to get people moved over.
Postgres has plenty of awesome data formats (JSON! Polygon areas!) that are rarely used, either because developers aren't aware, or Hibernate/ORMs don't support it, or devs only use features that are in all databases, you know, in case someone decides to switch dbs. Almost as you said below: Passwords are long overdue. They are lost, written down, or 1password becomes the single point of failure, keylogged, recoverab…
[deleted]
Re: Database leak exposes 3.3M Hello Kitty fans
#46> unsalted SHA-1 password hashes Can we please get password storage built in to databases as a dedicated column type already? There are N-to-infinity crappy languages and CMS's out there, but only a handful of databases. It's becoming clear that widespread standard library support for decent password hashing just isn't enough to get people moved over.
This is an interesting idea. I think you could take it a little further though.
How about databases explicitly disallow direct comparison or materialization of any field named 'Password', 'Passwd' etc. I'm aware that this would be a breaking change, and would require overrides to support legacy software. That said, the defaults would lead developers to a secure by default mindset. If n00b dev1 realizes that s/he can't store a password and get it back again, they go looking for why and find that the only way is to call something like:
SELECT IsPasswordValid(Password, @Password) FROM Users
UPDATE Users
SET Password = StorePassword(@Password)
Re: Database leak exposes 3.3M Hello Kitty fans
#47Evening project: union Hello Kitty and Ashley Madison lists. No, some things are better left unknown.
I'm not sure what compels people to download and look at any of these leaks. There's a real dichotomy between the mostly universal opinion on here that ad tracking is a terrible evil, but downloading and investigating people's private data that was illegally obtained and distributed is okay.
Often vegetarians will eat meat that was served to them by mistake. They don't want to contribute to demand for meat products, but if one has already been served to them it can't be taken back. There's no further harm in eating it.
Re: Database leak exposes 3.3M Hello Kitty fans
#48Earlier quoted context omitted.
This sounds like such an obviously great idea that I don't know how I haven't heard it before. Can someone who understands how databases are built explain why this isn't an obviously great idea?
The elephant in the room is what you return when you SELECT. My POV is you should be able to verify user sign-in with something like "SELECT COUNT(*) FROM users WHERE email = 'maaku@hellokitty.com' AND password='hunter2';", which has the added bonus of not informing the client whether the query failed because the user didn't exist, or because the password was wrong. Imho, all queries for the column content should sim…
If there are other ways to confirm whether a user exists or not (signup email check for example) --
I would add that the 'bonus' of not informing of the correct error provides minimal security gain and hurts usability.
Re: Database leak exposes 3.3M Hello Kitty fans
#49> unsalted SHA-1 password hashes Can we please get password storage built in to databases as a dedicated column type already? There are N-to-infinity crappy languages and CMS's out there, but only a handful of databases. It's becoming clear that widespread standard library support for decent password hashing just isn't enough to get people moved over.
Any good tutorial on how to deal with passwords? In a site of mine I generate a salt with UUIDv4 and generate a sha512 of the passsword+salt and store both the salt and hash. When the user authenticates I regenerate the hash and check. This is good, right? I still don't know how to deal with cookies/sessions though. And have no idea how basic http auth works. I'd search myself but I'm afraid to find a "bad" tutorial.
Re: Database leak exposes 3.3M Hello Kitty fans
#50So, are we going to see extortion attempts like in the Ashley Madison leak? "We know you like Hello Kitty"...
Not so much extortion, though it's certainly a gold mine for unscrupulous advertisers trying to sell Hello Kitty merchandise...