Why is userdata any more important than the rest of the data in your database?
You can impersonate a user with their login data, and given that people frequently re-use passwords, also do this on other sites.
Millions of accounts compromised because there is no specialised user database
31–40 of 61 posts
Re: Millions of accounts compromised because there is no specialised user database
#32There 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.
While technically you're right (as in, LDAP is great for handling many user entries and auth[nz] correctly), in practice it's not going to happen. Nobody knows LDAP (as in, take a random sample of non-corporate developers and most likely none of them will know LDAP). It's a pain to integrate and operate in a small environment. That's why there's a call for a simple solution.
It's why everyone uses JSON and not ASN.1. Why people will save a single number in a file rather than standing up Oracle database. Or why they still use random invented rot-level "encryption" for messages rather than pgp.
LDAP doesn't expose operations like "create new user", "verify password", "deactivate user", "set encryption method to ...". It's a database where you "bind" your user description against your hierarchy of objects/attributes - explain that to a guy who just wants to get his new app idea working ASAP... It's got its own query language too. You can even do LDAP query injections - just like in SQL!
Like you said - LDAP is a beast. It's great and I'd use it as soon as number of users goes over 10k, or employees on different levels over 10. But otherwise, no way. A new component with its own security issues is just not worth it.
Re: Millions of accounts compromised because there is no specialised user database
#33There 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?
LDAP is a network protocol.
It supports a lot of backends (SQL and NoSQL alike) (openLDAP has nice proxy features)
It also supports role based authentication.
But at the opposite of actual NoSQL data bases, even though it has no structures, it is strongly typed and secure.
You map your NoSQL structures to structured backend through a mapping.
It is awesome but most devs hates it, because they are (at my opinions) ignorants. And developers hates it because they are lazy.
Re: Millions of accounts compromised because there is no specialised user database
#34Earlier quoted context omitted.
True, but having been involved in the development of an LDAP client, LDAP is a horribly complex system to implement against (and its built on top of ASN.1, which is possibly worse) and it was slow to get security features (LDAPS, etc.)—and in many cases, no two LDAP servers work quite the same (the most common LDAP server, ActiveDirectory, is the worst for this). There is a need for something secure by default that i…
I've always wondered when I hear someone complain about the complexity, then where did it get the 'L' in its name from?
AFAIK LDAP is a simplified version of X.400, which was part of the truly horrible ISO protocol stack.
Re: Millions of accounts compromised because there is no specialised user database
#35There 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.
Can existing LDAP implementations scale a single directory to hundreds of millions of users?
I can find no clear answer after a few minutes of searching.
Re: Millions of accounts compromised because there is no specialised user database
#36Posted as a blog comment but I'd be interested in people's thoughts:
LDAP can be painful to work with, even when using such "industry standards" like Active Directory
I think a specialised server (or even Postgres extension) could be useful but couldn't you set up the following?
* Create a stored proc or similar that does this: SELECT COUNT(PasswordHash) WHERE Username = @Username AND PasswordHash = @PasswordHash
* Create a user account on the database that only has EXEC permissions, not SELECT or anything else
* Restrict the user account to only be able to log in from the app servers (or whatever)
* Restrict the DB admin to only login via a jump box / VPN.
Re: Millions of accounts compromised because there is no specialised user database
#37I wonder why is the call for a dedicated database, rather than for a simplified API instead? Many frameworks provide it already, but base it on the existing database which reduces the integration issues.
For example Symfony has FOSUserBundle [1] which provides nice support for most listed things. Django comes with its auth module [2]. There are more examples like that. They allow easy auth / user management without touching any of the underlying details. And once you actually want to go the direction of LDAP/kerberos/..., it's usually just a matter of switching the backend implementation for something that already exists.
[1] https://github.com/FriendsOfSymfony/FOSUserBundle [2] https://docs.djangoproject.com/en/1.8/topics/auth/default/
Re: Millions of accounts compromised because there is no specialised user database
#38This 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 l…
I’m working on an application where we have separated the Authentication concerns from the rest of the user data. When a user is registered, we generate a UID and communicate that with the other services. We’re going to be using common role terminology across the services, but Authorization is up to each service in relation to those roles. Our needs are a little different as well, because each service may need to rea…
Right, there's a few classes of data that can see that would do well to separate from the database that a website may have unfettered access to.
1) Authentication data (login id?, password) 2) Personal data that is not used in an online manner (depends on the site of course) (full name, email address, etc.) 3) Data that shows up on the site
If this data is segregated in to separate silos with no 'read everything' apis exposed to the web servers, you might stand a chance of not leaking all of your users data when the web servers are compromised. This of course will not help you if the authentication servers are also compromised.
Re: Millions of accounts compromised because there is no specialised user database
#39OP 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.
My beta-quality Golang version of this with pluggable backends, including S3: https://github.com/nmcclain/glauth
I would love suggestions/help.
Re: Millions of accounts compromised because there is no specialised user database
#40OP 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.
The article is pretty unclear on some basic concepts, such as salting and hashing wrong. This is a pretty well solved problem with bcrypt and other framework-driven identity mechanisms.
And It should encrypt data internally really gives no protection other than physical theft of the disk drive, as in if the portion of the application is compromised that can access the data, the key is available at that point, and the attacker has free run of that corner of the universe.