21–30 of 61 posts
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.
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.
There is a need for something secure by default that is easy to use, easy to set up, easy to deploy, etc. Where this will be difficult is https://xkcd.com/927/.
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…
But depend on an NSA aware third party to store your client's credentials?
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 l…
Our needs are a little different as well, because each service may need to reach out to a third-party service and we are holding a bearer token for the third-party service on behalf of the user. We provide that to the services behind an auth middleware through a header.
(We had considered changing this from an Auth Service to a general User Service, but I am strongly leaning toward having a separate User Service and leaving Auth tightly constrained.)
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?
I tried to find decent hashing in OpenLDAP and Apache DS but didn't. Perhaps I didn't look hard enough. Do they throttle by default?
Who's gonna make LDAP webscale and hipster friendly?
The core proposition of this article is that if we make it really easy to store user data correctly, people will do it. This proposition is simply not borne out by the data. Many parts of user security are easy. Take password storage, for example: it's so easy a caveman could do it. Every major languge has a library that takes a password and a salt and a number of iterations and runs it through pbkdf2 or scrypt. Many have these functions builtin. But do people do it? No. It seems like once a month some company exposes X-thousand passwords because they stored it in plaintext or MD5. And I bet a significant portion of HN readers think SHA1 is a valid way of storing passwords, eager to sacrifice security as efficiently as possible. pbkdf2 and scrypt aren't hard to use, people are just idiots.
Making a specialized database just gives people another easy thing to not use.
Ultimately there's no reason to be giving your password to a service in the first place. You only should be giving them cryptographic proof that you have your password, not giving them your password. This is possible with zero-knowledge password proofs[1], but it would require browsers and other client-side software to implement a ZKPP algorithm. This would force servers to either implement a ZKPP algorithm correctly or expose their incompetence to their users. Similar algorithms can be hypothesized for many other user data needs, but passwords would be an excellent start.
[1] https://en.wikipedia.org/wiki/Zero-knowledge_password_proof
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.
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…