With the progress of time – users, database administrators, developers, experts and all actors in the Internet World have embraced the truth that Passwords Break out. It doesn’t matter how secure the organization, no matter the effort of security experts and investments. There are ways to make this less of a problem from the user side and from the developer/application/service owner side.
From the User Side
- Don’t use Passwords at All – There are tons of Sign In With Options – Google, Facebook, Apple, Twitter, LinkedIn, Snapchat and more. This way you’ll “get in” faster, with less interactions, with less thinking. If something is wrong with the passwords in these companies, you’ll know and they will force you to change them or add some more security.
- Use Different and Long Passwords. Because once one Web Site breaches, the hackers will be able to log in any other Web Site that you’ve used the same password. Yes, the passwords this way are not impossible to memorize, but, don’t write them down on paper. The Browsers nowadays can save them. There are also bunch of services that keep the password and offer bring them to you across browsers & devices.
I’ve created a tool for generating Strong Passwords – as Android App or as a Web App. The longer the password – the harder it will be to be guessed. The more variations of characters – the more secure they (probably) are. Some platforms don’t allow special characters (or some of the other symbols), so I’ve included an option for skipping out some of the groups of types of characters.
From the Other Side
Because of security concerns, the creators of apps could walk away as much as possible from allowing users to type in passwords. The developers could include generators like the mine within the apps and web pages. Besides using the passwords – there are OAuth services from the big companies and institutions for logging into side services. After a User is registered, there are also bunch of layers that can be added that are described in a previous article about Authentication & Authorization. In Short these are:
- IP & Device white/black lists
- Temp Login Tokens (with Authenticator Apps)
- Securely protected Public/Private Keys. Developers could put in work bio-protected private keys and other type of securities that the devices provide. Fingerprints, face recognition, security screen and OS user account protections are standard features for medium to high priced devices. Example of this move away from passwords: https://www.theregister.com/2020/12/17/github_bans_passwords/
The best practices for encrypting passwords – if you need to do this is with Bcript with cost factor 10 or more. It is heavy operation, so the recommended best practice nowadays for authorization is public-private cryptography with lighter hashing. But this is for another article. Good Luck and may the Code be With you.