what’s in a password?

syd
3 min readFeb 16, 2021

--

Have you ever wondered where your passwords go and why you don’t get hacked by Mr. Robot? No…. oh, that’s just me and my obsession with cybersecurity and tv shows about hackers… gotcha. Well, lucky for you — we are going to dive deep into some authentication.

Whenever you login to an application you are asked to verify who you are with a username and password. But as web developers we can’t just store those passwords in plaintext out in the open (aka a database) because well it’s quite obvious but a little something called identity thief . So, how can the server still verify the users’ password is ‘hotgirlsummer808’ when us web devs can’t store said password in the database to check them against each other!? It’s called Bcrypt, which handles setting, salting, hashing and authenticating passwords.

Bcrypt is a cryptographic hash algorithm which basically means ain’t nobody gonna hack y’all!!! But for real, it’s kind of true. It takes a password and transforms it into a hash. It allows you to take the users password from ‘hotgirlsummer808’ to 13f26e560e402d895c5ce19d29492. This hashing mechanism is a great way to check passwords on a server! So if we want to register with a username and password — no one else will be able to learn our password because the password is not stored but instead the hash is stored. Whenever we log back in, the server takes our password that gets entered and performs the hashing function on it and then compares that hash with the one that is stored.

$ echo -n 'hotgirlsummer808' | shasum -a256
13f26e5a60e402d895c5ce1d9492d080563c5079a8b5f52a25953fd24a2cb1da

Not bad right? There is more though… since most people don’t pick complex passwords (like sij92746as20) but instead more guessable passwords. It is very possible, we may end up with two users that have the same password (hotgirlsummer808), now an attacker can compare the hashes to see that both users have the same password (which you guessed it — double the hacking and double the identity theif). But before we even hash our passwords, we can do something else to protect the users, we can use Salt.

{
"algorithm": "sha256",
"username": "syd",
"salt": "0a19471dab710025",
"hash": "4be637a8c85455dce0cdc1c7670f062764100276b6ed64141c06fbef4578f185"
}

Salt consists of adding a string of random data based on the type of computer, version of OS, and the time of day (plus some other factors) in front of the password before it is hashed (EX: 93c3b876k217e0hotgirlsummer808). The system will then store the salt and the hash with our username which will allow for more security and less hacking!

Now, let’s implement this in our code… Rails makes everything in life (well just in coding life) much easier! So if you haven’t already guessed Rails is going to do it again with a little method called has_secure_password. This method will add two fields to your ActiveRecord model: a password and a password_digest (these do not correlate to your DB columns but the method will expect to have a password_digest column defined in migrations).

What will happen is that this method will compare your password and password_confirmation, if it is a match then it will update the password_digest column. It’s that simple!

class User < ActiveRecord::Base
has_secure_password
end
<%# app/views/user/new.html.erb %>
<%= form_for @user do |f| %>
<%= f.label :username %>
<%= f.text_field :username %>
<%= f.label :password %>
<%= f.password_field :password %>
<%= f.label :password_confirmation %>
<%= f.password_field :password_confirmation %>
<%= f.submit "Submit" %>
<% end %>

Now, don’t forget to install gem ‘bcrypt’ and include some wonderful code to your UsersControllers and SessionsController, to help this method execute properly!

--

--

syd

software engineer. red wine addict. obsessed with vintage cars and jewelry.