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

Millions of accounts compromised because there is no specialised user database

fourlightyears.blogspot.com

Post reply on HN
Print view View original

11–20 of 61 posts

Re: Millions of accounts compromised because there is no specialised user database

#11

Post by danellis »

andrewstuart wrote: post #6

OP here. It's a fairly simple concept - any wizards with a few spare hours willing to try to put a prototype together today? From HN front page to solution within hours! If it said "built with Golang" or "built with Rust" it would certainly hit the front page.

It's a completely misguided concept. Database security doesn't mean having a completely different database implementation for each type of data you're using. There are already plenty of things you can do without going crazy like that:

* Put the user database behind a microservice

* Use a different connection with different credentials and put appropriate permissions on the tables

* Store password hashes using bcrypt, scrypt or PBKDF2

Not to mention that if you write a new database, what you're actually writing is brand new exploitable bugs.

Re: Millions of accounts compromised because there is no specialised user database

#12

Post by andrewstuart »

danellis wrote: post #11
andrewstuart wrote: post #6

OP here. It's a fairly simple concept - any wizards with a few spare hours willing to try to put a prototype together today? From HN front page to solution within hours! If it said "built with Golang" or "built with Rust" it would certainly hit the front page.

It's a completely misguided concept. Database security doesn't mean having a completely different database implementation for each type of data you're using. There are already plenty of things you can do without going crazy like that: * Put the user database behind a microservice * Use a different connection with different credentials and put appropriate permissions on the tables * Store password hashes using bcrypt,…

Misguided? The microservice you suggest is precisely what the post suggests. The post suggests that the code of the microservice ensures that the correct hashing is used and that the data is stored correctly.

It's puzzling that you say this is "completely misguided" and describe exactly the same thing.

Re: Millions of accounts compromised because there is no specialised user database

#13

Post by Spooky23 »

andrewstuart wrote: post #9
Spooky23 wrote: post #7

There is such a beast, it's called LDAP. There are any number of directory and authorization services, and they have probably been around for decades. There are dozens of directory server options, and probably a few dozen secure authorization solutions, from Kerberos and SAML to proprietary solutions like SiteMinder. Together, these solutions give you EIAM capability that does what you described.

My uninformed perception of OpenLDAP is that it is a large, generalised enterprise class directory service that does alot of stuff. The post suggests a minimal, lightweight user database that does nothing at all else - is that the same thing as OpenLDAP?

Pretty much.

I wouldn't characterize the magical detection of uncommon access patterns as a minimalist feature (it can be done, but not out of the box in a meaningful way), but other than that, all of the stuff you mentioned is there.

Typically, you use LDAP as a directory store, and a dedicated authentication protocol like Kerberos or SAML for authentication. You can also use LDAP for auth if desired.

If you want to go deep on identity management, the NIST documents are pretty much the canonical source of information. http://csrc.nist.gov/projects/iden_ac.html

In any case, don't reinvent the wheel. Just because bozos implement user auth in a MySQL table doesn't mean solutions don't exist. It just means that they are bozos. It's one of the reasons I disapprove use of SaaS apps that don't support federated identity at work.

Re: Millions of accounts compromised because there is no specialised user database

#14

Post by danellis »

andrewstuart wrote: post #12
danellis wrote: post #11

Earlier quoted context omitted.

It's a completely misguided concept. Database security doesn't mean having a completely different database implementation for each type of data you're using. There are already plenty of things you can do without going crazy like that: * Put the user database behind a microservice * Use a different connection with different credentials and put appropriate permissions on the tables * Store password hashes using bcrypt,…

Misguided? The microservice you suggest is precisely what the post suggests. The post suggests that the code of the microservice ensures that the correct hashing is used and that the data is stored correctly. It's puzzling that you say this is "completely misguided" and describe exactly the same thing.

OP called for "a specialized database". I was talking about using the same kind of database.

Re: Millions of accounts compromised because there is no specialised user database

#15

Post by andrewstuart »

Spooky23 wrote: post #13
andrewstuart wrote: post #9

Earlier quoted context omitted.

My uninformed perception of OpenLDAP is that it is a large, generalised enterprise class directory service that does alot of stuff. The post suggests a minimal, lightweight user database that does nothing at all else - is that the same thing as OpenLDAP?

Pretty much. I wouldn't characterize the magical detection of uncommon access patterns as a minimalist feature (it can be done, but not out of the box in a meaningful way), but other than that, all of the stuff you mentioned is there. Typically, you use LDAP as a directory store, and a dedicated authentication protocol like Kerberos or SAML for authentication. You can also use LDAP for auth if desired. If you want to…

Does OpenLDAP meet the stated need for a minimal solution that does nothing else apart from the small set of required functions?

I get the impression that OpenLDAP is a big beast that does much, much more.

I'm wanting a fast motorbike and you're pointing at a 16 wheel heavy hauler saying "see, same thing, the hauler has at least two wheels and an engine".

Re: Millions of accounts compromised because there is no specialised user database

#16

Post by BinaryIdiot »

This entry really boils down to separating user data from other data. But some of the items I don't think work in real usage (or at least I would like some clarification if possible).

> It should be accessible only via its specialised API which is designed to constrain the ways that it is accessed.

Constrained in what ways? Especially in management / support roles you may need to do bulk actions against users (full listing, bulk changes, etc) so I'm not sure what constraints would be compared to a normal database.

> Its API should have password salting and hashing built in.

I disagree; I think password hashing should happen before the data hits the database.

> Its API should throttle access with some sort of algorithm designed to prevent downloads of large quantities of user data.

Does someone have an implementation idea for this? Depending on the type of user data we're talking the data could be very small. So the throttling may have to be quite significant but even then what's to prevent the attacker from bypassing it by using multiple connections? Multiple threads that each request a subset? I don't think you can get around those and still have a performant system.

> It should encrypt data internally.

How? Does it encrypt using a passcode specified by the system administrator (which means it exists somewhere on the system or nearby system making it decrypt-able anyway)? Or does this mean encryption using the user's password thus separating the data? If so how do you handle the cases when administrators need to modify the user's information for support or other reasons?

Re: Millions of accounts compromised because there is no specialised user database

#17

Post by bearclough »

Welcome to the world of IAM (identity and access management). There are many solutions to the above stated problem. If you don't absolutely need to store it don't. That includes passwords, ssn, dob, or anything of the sort.

There are a ton of services you can federate with, it's easier for the user less passwords to remember.

If you really want users to authenticate natively. Take a look at one of the new-er players out there Storm Path. It's basically your IAM backend to-go. Don't write your own security if you don't have to :)

Re: Millions of accounts compromised because there is no specialised user database

#18

Post by Spooky23 »

andrewstuart wrote: post #15
Spooky23 wrote: post #13

Earlier quoted context omitted.

Pretty much. I wouldn't characterize the magical detection of uncommon access patterns as a minimalist feature (it can be done, but not out of the box in a meaningful way), but other than that, all of the stuff you mentioned is there. Typically, you use LDAP as a directory store, and a dedicated authentication protocol like Kerberos or SAML for authentication. You can also use LDAP for auth if desired. If you want to…

Does OpenLDAP meet the stated need for a minimal solution that does nothing else apart from the small set of required functions? I get the impression that OpenLDAP is a big beast that does much, much more. I'm wanting a fast motorbike and you're pointing at a 16 wheel heavy hauler saying "see, same thing, the hauler has at least two wheels and an engine".

Note I didn't endorse OpenLDAP at all. Not sure if that's the best solution -- I'd probably steer towards 389 server or something similar with Netscape heritage.

You also said:

"Another problem is that developers roll their own user and password management systems and get things like salting and hashing wrong, making the data vulnerable."

You're asking for a distributed, secure system for processing user data and credentials. The most common systems in production globally for doing this (Microsoft Active Directory) are based on technologies developed in the 80's and only being supplanted in recent years. There's a reason for that, and if it were a trivial problem, we wouldn't have pervasive solutions using 1980s RPC in 2015 still running most businesses!

Re: Millions of accounts compromised because there is no specialised user database

#19

Post by untog »

andrewstuart wrote: post #15
Spooky23 wrote: post #13

Earlier quoted context omitted.

Pretty much. I wouldn't characterize the magical detection of uncommon access patterns as a minimalist feature (it can be done, but not out of the box in a meaningful way), but other than that, all of the stuff you mentioned is there. Typically, you use LDAP as a directory store, and a dedicated authentication protocol like Kerberos or SAML for authentication. You can also use LDAP for auth if desired. If you want to…

Does OpenLDAP meet the stated need for a minimal solution that does nothing else apart from the small set of required functions? I get the impression that OpenLDAP is a big beast that does much, much more. I'm wanting a fast motorbike and you're pointing at a 16 wheel heavy hauler saying "see, same thing, the hauler has at least two wheels and an engine".

There is sometimes a reason for a piece of software being large. Security is one of those reasons.

If you want a secure system you shouldn't be prioritising a "minimal solution". As the previous poster said, don't reinvent the wheel.

Re: Millions of accounts compromised because there is no specialised user database

#20

Post by wmf »

andrewstuart2 wrote: post #3

The problem with this assertion is that this data still has to hit persistent storage somehow. Should that be in an arbitrary binary format? How should it be indexed for constant-time access? Essentially the problems that a specialized user database would need to solve would mean re-implementing exactly what generalized databases are built to do. It's not a problem of how it's being stored. It's a problem of what is…

I don't think the article is suggesting NIHing the stack all the way down. As I read the article I was imagining a layer on top of SQLite that exposes a very restricted API.
Post reply on HN