What is Tom Hanks' wireless password?
1forrest1! The fact that this joke is highly predictable may be a good thing for a stand-up comedian, but it's not so good for Tom Hanks.
The point is – although sometimes creating funny, witty passwords can sound tempting, the truth is – it's pointless because nobody should ever hear your password besides you, and your password should be way stronger than some quick joke.
But what makes a password secure?
Let's be honest- who hasn't tried to log into his sibling's or best friend's Facebook account or cellphone to send or post something embarrassing as a joke? If your face just stretched into a cheeky smile – don't worry; it happened to the best of us.
But, the truth is – the only possible way to do that was actually to guess the password, which is no easy task. But how saving the passwords without them getting 'stolen' actually worked – was always a mystery.
Today, we are familiar with the fact that as much as data security specialists and users carry a big part in securing an account, developers at all levels must play a role in it. Although it's well known that we have to be very particular when choosing a password for a newly created account, we've all felt the frustration of trying to pick a password that isn't too short, too simple, too predictable, too common, and simply too easy to guess by someone with malicious intents.
What you thought was a great password – actually isn't?
One of the most common misconceptions about passwords is that making them as complicated as possible - by using signs such as ˆ,&,#,!,and creating passwords like JoHn1997%$, will make the passwords more secure and our account or data more protected. That kind of password lead to a slow and inefficient log in process, and more importantly – they can be easily forgotten due to their complicated structure.
That's why a good practice in password creation is to use a technique suggested in the picture below. Another very helpful recommendation is to use that password as a master for a password manager (such as LastPass, NordPass, RoboForm, Dashlane, etc.), on which you can generate an infinite number of passwords, as well as store them and use them for logging into any existing account you have. All you need to do is remember one single strong password that unlocks your password manager wallet.
How to create a safe password?
One crucial fact to remember: a perfect, 100 % secure method doesn't exist, but the universal recommendation is that the password is 'safe enough' if a calculated time to crack it is approximately 100 years. That means regular users should use passwords at least 12-14 characters long, while privileged accounts (administrators and service accounts) should practice using even longer passwords. For privileged accounts, it is wise to consider implementing a Privileged Account Management (PAM) solution to further reduce the risk of privileged account compromise. We should also point out that, for example, people whose job is to test the security of passwords spend less than 8 hours to crack an 8-character password hash, but if it's only 2 characters longer, it takes them years.
How to create a safe password?
Even the most though-out password requires an additional layer of security – such as encryption, hashing and salting, processes that are regularly used in order to store data in a secure and confidential manner.
It’s extremely important to store passwords in an encrypted format that is robust enough so that even in the case of database getting stolen, the passwords are still secure and a hacker cannot obtain them – therefore is unable to use them. This is especially important for users who use the same password for multiple websites, allowing hackers to reach different accounts.
In order to meet our security requirements, our approach to password security is based on a combination of several methods and protocols.
How do we do it?
Since we in Devōt use Ruby on Rails to develop back-end, we are familiar with using bcrypt-ruby gem and has_secure_password method - which allow us to make those attacks on the app harder.
Bcrypt-ruby gem is a secure hash algorithm designed for safely storing passwords by using blowfish algorithm (yeah, you heard it right) - a symmetric encryption algorithm that uses the same secret key to both encrypt and decrypt messages. Blowfish is also a block cypher, meaning that it divides a message up into fixed-length blocks during encryption and decryption. If you want to learn more, you can find helpful info on this link:
So, what is hashing?
If you never heard of the term 'hashing', the easiest way to explain it is – a transformation process that produces some value from a given string.
The hash-function rapidly gained popularity in recent years, thanks to the rise of Bitcoin – in the Bitcoin protocol, hash functions are part of the block hashing algorithm used to write new transactions into the blockchain through the mining process.
To make things a bit clearer – the use of a 'hash-function' generates a new string using a mathematical algorithm, and the result of that function is called the hash value. This process helps protect the integrity of information, so its main goal is to serve as a 'one-way algorithm' that cannot be returned to the initial string after transformation.
Some well-known hashing algorithms are MD5, SHA-256, SHA-512, NTLM and LANMAN, but the vital thing to know is – with hashing, it doesn't matter if you have a one-sentence message or an entire book: the result will still be a fixed-length chunk of bits (1s and 0s).
For example, we differentiate SHA-256 from SHA-512 methods by the length of their results. If we run a string through SHA-256 algorithm, we will get a unique hexadecimal output of a fixed length. For example, SHA-512 converts string 'Lord of The Rings' to a much more complicated one.
That's because the example string is 256 bits, which display on our screen as 64 hexadecimal characters per string - for any given input, there are 2ˆ256 possible outputs. That means chances of guessing the input of a SHA-256 hash is 1 in over 115 quattuorvigintillion - since that number is bigger than a number of all atoms in the universe, it is safe to say that the chance of guessing it is next to nothing.
Hash algorithms are deterministic, so they will always return an output of the same size regardless of the length. On the other hand, if we use SHA-512, our digest would look like a 512-bit hexadecimal string. It's not hard to conclude from this that SHA-256 is a much faster algorithm.
If you want to try it for yourself and see what your name looks like in SHA-512 or 256, you can check out here:
What can we conclude about a hash function? The essential factors that make it good are its determinism, lack of collisions and hash speed.
How is hashing different from encrypting?
Suppose the concept of hashing still isn't quite clear, especially in comparison with encrypting. In that case, we need to emphasize the main difference: encryption is a two-way function, and hashing isn't (encrypted data can be decrypted with the proper key, while a properly designed hashing algorithm doesn't allow the hashed data to reverse and reveal the original password).
The encryption process turns plain text into a ciphertext that the invaders cannot understand if they succeed in intercepting your data – because the scrambled information can only be read by the user who has access to the security key or password decrypt the data. Some modern encrypting algorithms are Triple-DES Encryption, RSA Encryption, Advanced Encryption Standards….etc.
Considering everything, we can conclude that using hashing is much better because, with a properly designed algorithm, there is no way to reverse the hashing process to reveal the original password. Thus, stealing hashed files doesn't bring the hacker much use because the attacker cannot reverse the hashing process and access the original data anyway.
Salt, pepper and optimizing safety
This topic brings us to salt. No, we haven't gone entirely off-topic, and we are not talking about a mineral composed primarily of sodium chloride (NaCl), or a slang term for being irritated, angry, or resentful - we are talking about cryptographic salt. A cryptographic salt is made up of random bits added to each password instance before its hashing. So basically - it is adding random characters at the end of your password before hashing to force its uniqueness and increase complexity without increasing user requirements.
The other technique of making the hackers job harder is peppering (look at this guy with spices, huh??). It's similar to salting: a random bit of data is added to the password before it's hashed through an algorithm – but, unlike salt - it's not kept in the database along with the hash value. Instead, it is already added when a user enters a password, so the server doesn't store or need to see plain-text passwords.
Still, there are ways for hackers to 'guess' our password – because people usually don't use completely random passwords, so hackers can get a collection of a million commonly used passwords and run it through a hashing algorithm. By doing that, they get a list of associated message digests for these passwords - called a rainbow table. Now, it is very easy for a fast computer to compare a file of stolen password hashes against it, and for every match - the table will show the password for that hash. This process is better explained here:
So, what do we do?
Besides salt, another excellent protection method is called 'slow hashing' – these hashes are designed to be inefficient and slow, hence more difficult to calculate. The purpose of slow-hashing is to make brute-force attacks much, much slower, thus infeasible – and keeping your password safe.
In Devōt, we prefer to use this method, and some examples of slow-hashes we use are PBKDF2 and bcrypt.
Let's be honest - it is very difficult to find a perfect balance between safety and usability. More complex mechanisms demand more resources on the server and shouldn't be overdone – because the process can easily become too slow and inefficient. We know nobody likes rules - nevertheless, there are some general rules on making a good password that is simple enough to remember and complex enough to be considered 'safe'.
Authentication & authorization – what is the difference and what type to use?
Although the encryption protects data by scrambling it with a randomly generated passcode (an encryption key), the attacks on a database are still often – so we use encryption authentication to helps us protect our data from hackers. So what exactly authentication is? In simple words – it's a process that determines if someone's claim is true by using a secret or a piece of evidence called 'factor', and that claim is usually about their identity.
This process happens every time we sign into our e-mail account by providing our username and proving our identity with a password. Although Password-based authentication is the main method, there are other possibilities – such as Multi-factor authentication, Certificate-based authentication, Biometric authentication and Token-based authentication.
The authentication process is followed by authorization. To make it harder for someone to gain access, we can use two-factor authentications that require users to input a password and a one-time code texted to their phone before logging in.
Similarly, a company might require employees to present both an ID card and fingerprint scan to access a sensitive dana or restricted area. In simple terms, authentication is the process of verifying who a user is, while authorization is the process of verifying what they have access to.
Let's put it all to practice – how does it work?
After all this explaining, there may be more questions than answers in your head. We get it – this process of data protection and security may not be an easy read, but it is well worth the effort. Let's put all of the aforementioned processes and methods in one example:
You type in a plain password - then it comes to our back-end application which generates and append salt on it, and then computes the hashed password. Finally, it stores your username, salt and the hashed password into the database (it never stores plain passwords or unhashed passwords). As far as the authentication is concerned, when the plain password comes to the back-end application from the client, the backend application gets user-specific salt from the database and append it to the plain password, it computes the hashed-password using the same hashing algorithm and compares it with the stored one – so it can be sure it is you accessing your account.
Your Job Is Not Driving You Anymore? Consider a Career Switch!
Once you feel your passion for the job is gone, and Sunday evenings become the definition of anxiety, you know there is no turning back. It's definitely time for a major change. Finding the inner strength to do it could be the most challenging part. Read about a real-life example of that change.Read
How to Implement Sign In With Microsoft Using the Office 365 Omniauth Strategy With Rails 7
Learn how to create a fully working “Sign in with Microsoft” authorization button, which functions exactly the same way as the ones that we see everywhere online. After you learn this, you will have no issues implementing other Omniauth strategies on your own. In just three steps, you will be able to make your life easier.Read