The password problem is one a lot of people are trying to solve. From password storage solutions to QR-based systems, to cryptographic dongles, there are a lot of different ways people are trying to prevent you from having to remember yet another password. I wanted a solution that didn't involve giving the keys to my online kingdom to some third party service. Even if it was perfectly secure, microservices come with reliability risks, and may not be supported everywhere.
I began using openssl's passwd command line utility to generate hash strings, using one master password and the account domain as a salt. This would deterministically give me the same hash every time for the same given domain. For example:
$ openssl passwd -1 -salt gmail $ Password: password $1$gmail$3MRBFeUN/FzLj6Wq/LXKq1
Using the salt 'gmail' and the password 'password' will result in the same hash every time. Given a different password, a completely different hash would result. I used these salts with my master password for a while, and it worked well. I had a different password for every site I visited, but I only had to remember one. Some obvious problems started to arise, though.
For starters, if one of my hashes was compromised or needed to be changed, I would have to give either a different salt or different input password, breaking my design. The other issue was that I had no control over the length or content of the hash, so if a site required no use of special characters or capital letters, I was out of luck.
I created a GUI to make the practice I developed a litte more official. One of the features I wanted initially was the ability to avoid copying and pasting the password hashes. This is an insecure method of transporting the password, since any application running on the system has access to the clipboard, and can snatch up the password easily. The Send button allows you to take the hash that you have 'loaded' and 'fire' it into a text field. It does this through the Windows API, emulating keypresses.
Eventually, I redesigned the hashing algorithm to allow for customization of the hash. Using SHA-256 as a base, the app could remember domain-specific settings and output a custom hash. Now, for example, your apple.com password could be 64 characters long and include only lowercase letters. I also added an iterations counter, which allows you to generate a new hash with the same input - solving the compromised hash problem.
Now that I had all my accounts using big long secure passwords, I quickly found that trying to log into anything outside of my computer became a huge hassle. I needed to get my passwords on to my phone, so I made a mobile version.
The mobile app is a quick recreation of the desktop application. It has all the same settings, but does not currently remember any domains. Adding and choosing domains couldn't be done the same way as on the desktop, since there is no mobile equivalent of a combobox that allows text input.
Going forward, I would like to significantly improve the mobile interface. I would also like to add a permanent per-user salt to further bolster the security. One way to transfer this user salt to the mobile app would be via a QR code scan, which would be a quick intuitive interaction.