Day 38 - April 15: Refreshing my password security knowledge

Quick recap of a talk by Joe Manico about password security which updated me on the best practices and some tips for bootstrappers implementing their security workflows.

Mentioned in this episode

Transcript

Alex: Good morning future, Alex. It is day 38. Today it's April
the 15th. And because I was part of a webinar by Joe Monico, an IT security
expert who talked about password security yesterday, I'm just gonna quickly go
through what I learned.

[00:00:14]Number one is you don't want to restrict the
length of your passwords, but you have to be careful not to allow unlimited
inputs into your cryptographic algorithms that take up time and resources. You
could basically this way create a DDOS attack on your own system. So Joe
proposed a solution which was to allow any size inputs for the password but put
that into a non cryptographic fast hashing function like HAMC512 and then use
that as a normalized input into your cryptographic algorithms which circumvent
that problem.

[00:00:49]Number two was a quick update on the actual
cryptographic algorithm you want to use. The industry standard is to use a.
Time or resource based algorithms or something that takes quite a while to
calculate in order to make it hard for an attacker to calculate many hashes at
once. Bcrypt was what I was used to using now. There is Scrypt and Argon2 which
not only have a time parameter so it delays the calculation, but also a
resource parameter, which means it takes more resources like Ram to
calculate. 

[00:01:24]Last but not least on the new insights was a
device called the YubiHSM. So an HSM generally is a hardware security module,
which takes care of cryptographic functions like hashing inside, for example, a
USB key. Now Yubi is known for its YubiKey, which is a personal security
device, and I didn't know up until yesterday that they also produced a device
for providing that service to servers. 

[00:01:54]And then there were a couple of things worth
reiterating just to make sure that you're doing them in your security workflow.
First, don't prevent people pasting into your password field. It's bad
practice. For some reason, there are actually security audits that flag that as
a issue, if it's not present as a brute force attack, I'm going to link to a
Troy hunt article on this to read more about it, but in general don't.

[00:02:19]In addition, test your website with common
password managers because oftentimes you may have implemented something that
blocks them from working using their auto type mechanism or their auto fill
mechanism.

[00:02:35]Another common mistake which happens due to use
ability very often is on your forgot password form. If the user enters an email
address that does not belong to user account, you will often see an error
message saying this user does not exist. Please try again. But by showing this
error message, you have confirmed that this email address does or does not
belong in your database, so an attacker can go and find out if Jeff Bezos is
your customer for example, so you don't want to do that there. You want to not
display an error message either way you want to say we have sent an email. And
you want to actually send an email in both cases. So if the user account
exists, you send them the reset link. If the user account does not exist, send
them an email as well, but tell them that that account does not exist so that
only the person who owns that email address gets the information.

[00:03:29] Now that second part with sending an email in
both cases is also important to prevent a timing attack if the server response
to your. System requires a longer in one case, so if the user account. Is
created because you're sending an email but it does not require as much time in
the case that the user account does not exist well then it's very simple for an
attacker to figure out which email addresses are in your database and which are
not.

[00:03:58]Of course, add CAPTCHAs to your forgot password
forms and have some form of lockout mechanism for failed login attempts, but
beware not to open yourself up to an attack where a hacker will try multiple
user logins. And lock out users from your service that way.

[00:04:17]Last but not least he recommends outsourcing
security authentication and possibly even authorization to a third party
service that specializes in those services. Auth0 comes to mind which I've used
in the past. I'm a bit on the fence on this. I don't like transmitting user
data to a third party service, but at the same time, yes, they will always be better
at providing industry best practices compared to me as a solo bootstrapper.

[00:04:50]All right, that's all for today. Share the
episode. If you think someone could benefit from it. Or go to futurealex.com to
subscribe and for a full transcript and any links that I've mentioned. I will
talk to you tomorrow.