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

Database leak exposes 3.3M Hello Kitty fans

csoonline.com

Post reply on HN
Print view View original

31–40 of 57 posts

Re: Database leak exposes 3.3M Hello Kitty fans

#31

Post by nononoxd »

nly wrote: post #23

> 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

#32

Post by nly »

maaku wrote: post #24
nly wrote: post #23

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

That is a decent idea I've never heard of before. Have you tried submitting an issue to various database issue trackers?

No, because even this would be a total cock-up. Don't give anybody your password, and just can't mess it up. So i'm not really in favour of fixing backends at all. I think the password problem is entirely the browser vendors reponsibility. Solid password authentication already exists in TLS (which you need anyway), it's just not widely implemented or exposed via browser UIs.

There are too many vested interests from the big players, where the hope is that deliberately making authentication ever more burdensome for users will just lead them to give up and select 'login with Facebook/Google/Live' and hand them the keys to the kingdom.

Re: Database leak exposes 3.3M Hello Kitty fans

#33

Post by nly »

dopamean wrote: post #28
nly wrote: post #23

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

Re: Database leak exposes 3.3M Hello Kitty fans

#34

Post by bhauer »

dopamean wrote: post #28
nly wrote: post #23

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

One thought is that it puts the computational load of verifying user-provided passwords in your database tier, rather than in your application tier, where it exists today. Let's say that right now, you have a 200ms computation necessary to verify a bcrypt-secured password. If you have that in your application tier, you can easily scale that horizontally with more CPUs if necessary. It may be a bit more difficult to scale CPU capacity in the database tier.

However, another approach would be extension of the database's client-server protocol and driver(s) such that the hash verification occurs within the application tier (as part of the driver). Or, moving further along that path, the field could be annotated in your ORM, exposing special set and verify methods. But at that point, you're very close to the current condition, where the hashing occurs within your web application framework.

Or hashing could be done on the client side.

Re: Database leak exposes 3.3M Hello Kitty fans

#35

Post by j_jochem »

nononoxd wrote: post #31
nly wrote: post #23

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

Just use one of the existing key derivation functions. Scrypt and bcrypt should be good enough for most use cases, but you may want to google a bit before settling on one.

Re: Database leak exposes 3.3M Hello Kitty fans

#36

Post by tajen »

nly wrote: post #23

> 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, recoverable by email, prone to brute-force or more clever attacks, the user types them in the username field (my security teacher did exactly that in front of the whole class while saying it), or worse, in the group chat window that just popped up...

We needed Persona. We needed an open marketplace for password replacement. Bash & SSH have pretty much gotten rid of passwords. I'd bet a year in prison that Mozilla has been served an NSL and ordered to shut down the project.

Re: Database leak exposes 3.3M Hello Kitty fans

#37

Post by nly »

bhauer wrote: post #34
dopamean wrote: post #28

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

One thought is that it puts the computational load of verifying user-provided passwords in your database tier, rather than in your application tier, where it exists today. Let's say that right now, you have a 200ms computation necessary to verify a bcrypt-secured password. If you have that in your application tier, you can easily scale that horizontally with more CPUs if necessary. It may be a bit more difficult to s…

> Or hashing could be done on the client side.

Only if you use a proper PAKE. A vanilla password hash is still a bearer token on the wire.

Re: Database leak exposes 3.3M Hello Kitty fans

#38

Post by DCoder »

nly wrote: post #33
dopamean wrote: post #28

Earlier 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…

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.

Re: Database leak exposes 3.3M Hello Kitty fans

#39

Post by eli »

nacs wrote: post #12
eli wrote: post #8

Earlier quoted context omitted.

i.e. the default configuration But yeah, that's not good.

> i.e. the default configuration The default configuration for MongoDB is to listen on localhost only. Someone changed the configuration if it was listening on a public IP.

Some official distributions listened to all addresses by default (by design) until recently. https://blog.shodan.io/its-the-data-stupid/

Re: Database leak exposes 3.3M Hello Kitty fans

#40

Post by whywouldyou »

pavel_lishin wrote: post #25
whywouldyou wrote: post #22

Earlier quoted context omitted.

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.

> the mostly universal opinion ... downloading and investigating people's private data that was illegally obtained and distributed is okay [citation needed]

It's a prevalent cadence when the topic comes up. Granted, people opposed to ad tracking are likely more vocal on the topic than people for it.
Post reply on HN