So from what I’ve been able to find, by adding the
has_secure_password to the User model in the last (or maybe the one before that) exercise, we enabled what is essentially the auto-hashing of the password whenever it is entered.
So the User model contains
class User < ActiveRecord::Base has_secure_password end
The first line draws methods from the parent class ActiveRecord.
The second line adds method
So when there is a password being used it calls on that method which is contained in the
ActiveRecord::SecurePassword module (which is part of
has_secure_password method contains the code that hashes the password and passes it into the
:password_digest attribute and only the hash is stored (password is discarded and never saved). (see more about the ActiveRecord::SecurePassword method here)
It looks like the SitePoint tutorial is literally doing the authentification from scratch. The tutorial doesn’t add the
has_secure_password method to the model nor does it use the required
:password_digest attribute which is required for the
has_secure_password method. (see the source code of ActiveRecord::SecurePassword in the link.) The method that is being proposed in that tutorial is an expansion of hashing. It’s designed to prevent hash lookup/rainbow/reverse-lookup tables. (Two really good articles about hashes and hash security can be found here and here and I had a third but lost it .)
[I think part of the confusion might also be due to the difference between encryption and digesting. Encryption involves having the cleartext password being converted into ciphertext and back, while digesting is a one-way process. The BCrypt algorithm digests the cleartext password into a hash and then Ruby is storing the hash in the app. The cleartext password is discarded and never saved anywhere. When a user logs back into their account, the password is digested and the hash is compared to the one stored in the `password_digest` column. If there is an exact match, then the user is logged in. This is done so that in the event the server is hacked, there is no database that contains cleartext passwords. Although the hacker could log into the hacked system (using a rainbow or lookup table or a script to match hashes if the encryption is known), they would not have the actual password the user types in. This provides security in case the user has reused the password. The password method in the SitePoint tutorial uses a random salt which will help make it nearly impossible to determine the password that was used to generate a hash. The SitePoint tutorial calls the digest an encryption, which it is technically not.]
Hopefully that kinda answers the when and how the exercise is doing the hashing. It’s basically being done behind the scenes through some Gem code that we aren’t really seeing. It would definitely be great if they had explained some of this in the lesson!