I assumed they meant largest economy?
1,372 karma · joined October 13, 2016
I think MFA is important and have it enabled for every service that offers it, but we have MFA set up for our CLI access to AWS and I used to let out a volume of curses frequently when my token expired.
I eventually ended up adding a bash alias “damn”[0] that pipes my current MFA token into the AWS CLI so whenever it expires I can just type “damn” and be logged back in.
I like the magic link approach Slack and Medium use - although I have frequently cursed the inconvenience of having to log into gmail.
[0] why damn? Fuck was taken: https://github.com/nvbn/thefuck
Using something like Hashi Vault, Gluu, or Shiro does not overly complicate things. They’re stable, trusted solutions.
It can also greatly simplify things. In the common scenario of having a web app for customers and a web app for admins, instead of them each having their own authentication baked in, you can choose an open source solution and deploy it twice, once for each service.
I know how salt works. Don't belittle me.
If someone gets into your web servers they’ve pretty much got carte blanche at your database the web server has access to. They also now have your code, which in a lot of cases is probably plainly readable. So they can see your salt, see how you salt and see the hashing algorithm you've chosen.
I’m saying don’t store the salt in your apps config right along with the credentials to access all of your login identifiers and hashed passwords.
You gave them a piece of the puzzle. If someone wants to grind through and crack all the salted/hashed passwords, I'd prefer them not to have the salt to help in that endeavor.
If you want that to be a REST service, great.
If you want it to be another table/schema/database/server, great.
If you want it to be something else, great.
Just stop putting it right inside the application that is taking user input.
Don't roll your own hashing, use something solid, like Argon2, salt your stuff. Store your salt someplace secure, not in your frigging rails config.yml or inside env on your webservers or anything else that is publicly addressable.
Do you jam all your tables into one public/default schema? Or do you break them up by domain across schemas?
A very simple implementation of this in Postgres is an auth schema. Only one role can read from the table with the credentials, no app has access to that role. You write a function to verify a credential and use a security definer to give a role that can use that function access to read a single result.
In this case you’ve mitigated two “attacks”:
- a sql injection selecting all from users
- some random engineer taking a schema dump for whatever purpose, accidentally grabbing auth details and then having that get leaked somehow down the line.
I literally takes a few lines of SQL to set that up. It’s not an extra server to manage. Just a different schema with higher security constraints.
From your app with the credentials to call that compare function instead of doing a SELECT FROM you can call that function with the credentials and just accept Postgres telling you yes or no the credentials matched.
PG has a suite of hashing functions. Take your pick. That function can do your salting or you could add it as a parameter to the call.
If someone wants to go exercise 9384828388 GPUs on your list. Fantastic, at least the other piece of their auth username/etc isn’t sitting right next to it.
Putting them in a separate system can be a simple REST server that sits in front of another database, LDAP or even something like Vault.
Don’t set them right alongside your ecommerce app you’ve got 30 juniors hacking on trying to get something out ASAP.
I also never said “write your own hashing algorithm” I said abstract it so it’s not sitting around in your ecommerce app code.
That is a simple security system. It’s just not baked into your flagship ecommerce, blog or whatever else your storing the credentials to protect.
You can easily put any open source security system behind a secondary system. Hell - it would already be a secondary system.
Not putting your passwords right next to the identifiers is a simple way to lower the impact of an email or password leak.
Also, that quote is bullshit.
Also I left the link off above ^
Another table, another database or another storage system in general.
If an attacker SQL injections your database don’t go spilling every hashed or unhashed password you’ve got.
I tend to store passwords in a separate keyvalue store from where my authentication identifier is (email, “username”).
If someone gets into my network they need to get into my servers with the email addresses and then get into a secondary system where the passwords are stored.
I like my password systems to be a k/v store because there is no need to “query” it. I usually store the password under a key that isnt the identifier. Instead using something like a database surrogate key.
Have a secondary system (microservice, private subnet) that simply returns a boolean representing if the provided non-email (key) and password (value) match.
Have that secondary system take the plain text password so it can do the hashing without letting the dependent service know what algorithm, salt or stretches you’re doing. This will also allow you to easily roll over to new hashing algorithms over time without affecting the service that is doing th authenticating.
Edit: I’m not trying to be a know it all or a crabby old tinfoil hat a-hole. But it’s passwords, man. When you leak them you ruin people’s days/year/life. Building that system above takes a middle of the road engineer a day or two. Put the effort in. Every password leak makes all of our jobs harder. It’s your companies responsibility to keep that safe. If you know that already, be the annoying guy that brings it up in every stand up. Make that debt known.
Maybe salt your passwords, use some stretches, and a decent algorithm instead of MD5, SHA1, etc.
Also stay up on algorithms and roll your users over to new ones over time.
If you hit two valid accounts [1] with bad passwords in a few ACCEPTABLE_UNIT_OF_TIME, it’s captcha time.
Thresholding isn’t just action per IP it’s being smart about how people are going to attack your system. It requires thought and upkeep.
[0] Previous thoughts on bot detection: https://news.ycombinator.com/item?id=16182405
[1] Also, if your login identifier and your public “display names” (usernames) are the same thing, that is a disservice to your users’ security.
Either you have some EXTREME legacy or lazy engineers. Doing it right doesn’t take long.
Nice stereotype though!
If you do it all the time, you’re inconsiderate.
It would probably require a few different categories with some sort of output assertion to validate the query performed right and a means of tracking CPU, usage ram usage, and execution time.
It would be cool to see things like disaster recovery and chaos proofing as well.
I’m a little jealous.
I am finding that I use it less and less each year. How much are you using it compared to previous years?
- My friend communication is done almost strictly through messaging services
- work communication is done through Slack and Jira (yuck)
I feel like email for me has become this awkward auth-proxy.
It’s how I magic link in, “confirm” who I am, reset my password, or get spammed by marketers.
Actually I suppose the post office is the UDP way too.