Application Security is one of the primary concerns for a software developer. People trust your application and share sensitive or personal information. As a software developer, you need to take care of your application user information security. Authentication and authorization both play critical roles in application security. They confirm the identity of the user and grant access to your website or application.
\nThe process in which confirm the user's identity and provides access to sensitive information is called authentication. Generally, authentication is done through the email/username/password. Authentication using the password is the older and common way, so passwords are a critical component of user's identity security. Password policy is the front line of defense to protect user identity. However, weak passwords may violate compliance standards. A simple or common password could be reversed engineered back to plaintext and sold on the dark web, or result in a costly data breach if compromised.
\nPassword policies and compliance are rules and methods that enforce the user for using a secure and robust password. A billion credentials were stolen last year from multiple data breaches. According to Verizon's Data Breach Report, 81% of data breaches are caused by compromised, weak, and reused passwords. According to National Cyber Security Centre (NCSC) recent analysis, millions of peoples are using easy to guess passwords like 123456. Recently a security researcher claimed he hacked President Trump's tweeter account by guessing his password maga2020! so now we can understand the need for Password Policy & Compliance. You can check the top worst passwords list here.
The Minimum password age policy is to decide how many days minimum users must keep a password before changing it. This password policy.
\nThe \"Enforce password history\" policy is used to make sure the number of unique passwords a user must set before reusing an old password. This is an important policy because password reuse is a common issue – the user feels more comfortable with the old passwords. Using the same password for a long duration for a particular account, it will create a strong chance for the password compromised in some way, such as in a brute force attack. Password age policy shouldn't be efficient until the password history policy. Users must change their password, but they can reuse an old password; the effectiveness of a password age policy is greatly reduced.
\nThe Minimum Password Length policy decides the minimum number of characters needed to create a password. Minimum Password Length should be at least eight characters or more. Longer passwords are generally more secure and harder to crack than short ones. For even greater security, you could set the minimum password length to 14 characters.
\nThe Passwords Complexity Requirements policy make sure user shouldn't use basic passwords. Passwords should be a combination of uppercase, lowercase, and numbers also include some special characters. We can set the following policies in the password Complexity Requirements.
\nThe Password must use following characters combinations
\nThe users shouldn't use the common passwords, so Restrict the use of common passwords. You can refer to this document for a common password list maintained by LoginRadius and this list is dynamic, and it gets updated from time to time.
\nA Password dictionary is a file that contains a list of potential passwords. This feature prevents your user's from setting a password available in the dynamic password dictionary. We are using this dynamic Password Dictionary in the LoginRadius to prevent the use of dictionary passwords.
\nEnabling the Password Audit policy allows you to track all password changes. By monitoring the modifications that are made, it is easier to track potential security problems. This helps to ensure user accountability and provides evidence in the event of a security breach.
\nPassword compliance is a set of rules to enhance user's data security by encouraging users to use strong passwords and use them properly.
\nThe FDA regulates the set of rules for the food, drugs, biologics, medical devices, electronic products, cosmetics, veterinary products, and tobacco products Industries.
\nPasswords for FDA Industry Systems accounts must meet ALL of the following requirements:
\nThe Health Insurance Portability and Accountability Act (HIPAA) enforce a set of rules for sensitive patient data protection. Companies that deal with protected health information (PHI) must ensure HIPAA compliance.
\n!@#$%^&*()_+|~-=\\'{}[]:\";<>?,./;PCI is the set of rules or guidelines for the businesses that are dealing with payment card data.
\nNIST creates a set of rules or guidelines for the businesses that are providing services to the federal government. These guidelines to help federal agencies meet the requirements of the FISMA; however, other organizations reference NIST for strong security standards.
\nI have explained why we needed a strong password policy & compliance. It doesn't matter how strong a password you are using, but bad guys are using new methods or technologies for exposing the user data.\nMost of the data breaches are happing because of Common or weak passwords. MFA, passwordless, or one-time password are providing additional security for a user account.
\nhttps://www.fda.gov/food/online-registration-food-facilities/random-password-generator-fda-industry-systems
\nhttps://uwm.edu/hipaa/security-guidelines/#password
\nhttps://pcipolicyportal.com/blog/pci-compliance-password-requirements-best-practices-know/
\nhttps://spycloud.com/new-nist-guidelines/
\n","frontmatter":{"date":"November 12, 2020","updated_date":null,"title":"Password Security Best Practices & Compliance","tags":["Security","Password","Compliance","Passowrd Policy"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/f1b48d682872b6c2f7aee16ea458d6ad/14b42/password-security.jpg","srcSet":"/static/f1b48d682872b6c2f7aee16ea458d6ad/f836f/password-security.jpg 200w,\n/static/f1b48d682872b6c2f7aee16ea458d6ad/2244e/password-security.jpg 400w,\n/static/f1b48d682872b6c2f7aee16ea458d6ad/14b42/password-security.jpg 800w,\n/static/f1b48d682872b6c2f7aee16ea458d6ad/47498/password-security.jpg 1200w,\n/static/f1b48d682872b6c2f7aee16ea458d6ad/ec6c5/password-security.jpg 1280w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Vijay Singh Shekhawat","github":"code-vj","avatar":null}}}},{"node":{"fields":{"slug":"/engineering/password-secure/"},"html":"When we start thinking about authentication in any kind of software (it can be web, mobile, desktop, or even console), the first thing that comes to mind is username/password, this is an older but still effective technique to protect and identify users. Securing these passwords is not an easy task we require better techniques to secure these passwords from attackers. Generally, passwords stored in databases, so we can secure passwords by traditional techniques to prevent access to databases like firewalls, role definitions, etc. but just to prevent database intrusions is not a fully secured way, we require further password protections by converting them into non-readable (encrypted) formats. To understand encrypting passwords we have to understand plain text passwords and how these kinds of passwords are insecure.
\nLet's start our journey
\nPlain text passwords are stored directly in a database without any encryption. These passwords are very insecure because:\n- If someone hacks your database he can access any account and do anything possible after login.\n- Developers or employees who are working on a project commonly misuse the password and spread these passwords to other people for misuse.
\nAs a hard and fast rule plain text passwords should NOT be accepted in any case or used for any project or product.
\nEncryption helps us by protecting data from hackers. In network communication, the same techniques can be used in saving passwords. Any encryption algorithm can be used to protect passwords. So on registration plain text passwords are encrypted and saved to your database.
\n```\nEncryptedPassword = Encrypt ( Password, Key);\n```Get this encrypted password from database then de-crypt and match\nPassword = Decrypt ( EncryptedPasword, Key);
Match with user entered password.
\nBut passwords will still not be fully secured because encrypted data can be always be de-crypted with the encryption key if someone get the key then they can de-crypt your password.
\nHashing is a method of encryption to get original data from hash. Hashing algorithms are used in network data communications. The encryption encrypts the data but hashing protects tampering with the encrypted data. Hashing algorithms are widely used in securing passwords.
\nIn case of hashing validation of password performed refer to the following pseudo-code:
\nOn registration
\nPasswordHash = HASH(Password);Some of the hashing algorithms support salts(a set of characters that is appended to your hash) like HMAC
\nPasswordHash = HASH(Password, salt);On login the same process happens, get hash from users entered password
\n inputPasswordHash = HASH(inputPassword);And compare with the saved password
\n If(SavedPassworHash == inputPasswordHash){\n\n //user get login\n\n }For making a strong hash from non-salted hash algorithms, salt is appended or prepended to your password string. Appending and prepending also has two kinds of implementations one is a universal salt and the second is per password random salt, let us understand one by one.
\nUniversal salt : in this implementation every password has one salt.
\nUniversal salt prepend
\nPasswordHash = Hash(Salt+Password);Universal salt append
\nPasswordHash = Hash(Password+Salt);Per password salt :
\nIn this implementation every password has it's own random salt, but the question is how we preserve salt for a password? Answer is the salt is appended with password by a separator. And on login split that saved string by separator and get hashed password and salt.
\nOn registration when we save password
\n Salt = RandomString();\n PasswordHashWithSalt = Hash(Password+Salt) + ":" + Salt;On login when compare password : first split salt and password hash
\n StringArray = Split(PasswordHashWithSalt , ":" );\n Salt = StringArray\\[1\\];\n PasswordHash = StringArray\\[0\\];Than get hash of user entered password by salt
\ninputPasswordHash = Hash(inputPassword + Salt);Then compare both password hash
\nIf(PasswordHash == inputPasswordHash){\n\n//user get login\n\n}Some popular encryption methods : Most of people use following algorithms for hashing passwords, explaining all algorithms is out of scope of this blog. I am adding reference URLs for more reading. I am adding only strong hashing algorithms
\n\nBrute force: It is the most popular password cracking technique, in this loop every combination of numbers and alphabets are tried. Suppose one system have password minimum length is 6 digits then
\n000000, 000001,000002……………….111111,111112……..AAAAAA etc.
\nIn any case user have set simple password like 123123, it will be cracked simply. How to prevent this kind of scenarios
\nDictionary attacks:
\nIn crypt-analysis and computer security, a dictionary attack is a technique for defeating a cipher or authentication mechanism by trying to determine its decryption key or pass-phrase by trying hundreds or sometimes millions of likely possibilities, such as words in a dictionary. (Wikipedia)
\nit is just extended version of brute force attack, in this attacker attack by dictionary words, most of time people set their password as meaningful name to keep easily in mind. And in this attack.
\nRainbow tables
\nA rainbow table is a precomputed table for reversing cryptographic hash functions, usually for cracking password hashes. Tables are usually used in recovering a plain text password up to a certain length consisting of a limited set of characters. It is a practical example of a space/time trade-off, using less computer processing time and more storage than a brute-force attack which calculates a hash on every attempt, but more processing time and less storage than a simple look-up table with one entry per hash. Use of a key derivation function that employs a salt makes this attack unfeasible. (Wikipedia)
\nSometimes people realize that their Hashing algorithm is weak so they think to migrate system to one algorithm to another but hashing algorithms are one way so getting original password is not possible so the question becomes how to make this possible. There are two ways to do this.
\nReset all passwords: In this approach just migrate your algorithm from one to another but keep password hash same, but password will not be matched because hash of one algorithm doesn't match with hash of another algorithm, so email to user about it that our system has improved security system and send link with this email for resetting password, so user will reset password.
\nMigrate on login: this approach is tricky in this case maintain one parameter for checking is password upgraded to new algorithm, set false for all user by default and when use come for login check this check if it is false then compare password with old algorithm and if password get matched then start user's session and get newer hash from plain text password and saved to database and update is password upgraded check to true. Now from next time user's password will be checked by newer algorithm.
\n","frontmatter":{"date":"May 14, 2015","updated_date":null,"title":"Password Security","tags":["Security","Password"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1,"src":"/static/e7bb89604f85c7699b36ea7c43eab30e/7d145/password-security.png","srcSet":"/static/e7bb89604f85c7699b36ea7c43eab30e/69585/password-security.png 200w,\n/static/e7bb89604f85c7699b36ea7c43eab30e/497c6/password-security.png 400w,\n/static/e7bb89604f85c7699b36ea7c43eab30e/7d145/password-security.png 610w","sizes":"(max-width: 610px) 100vw, 610px"}}},"author":{"id":"Kundan Singh","github":null,"avatar":null}}}}]}},"pageContext":{"tag":"Password"}},"staticQueryHashes":["1171199041","1384082988","2100481360","23180105","528864852"]}