I've been pondering how to deal with passwords lately. I'd been using a password manager for awhile, but this means I can't access anything I use it for from a machine where it isn't installed (or where I can't install things). I got to thinking that sha256 is available pretty much everywhere, so a pw generator based on that would be as portable as possible. (I might even write an html file, keep it on a thumbdrive, and load it on a browser on any machine, using JS functions to do the hashing...) Here's a bash implementation:

echo -n "Code: " && read CODE
echo -n "Password: " && read -s PASSWORD
for i in `seq 5 -1 1`; do
clear && echo $i
sleep 1
done &
for j in `seq 1024 -1 1`; do
    PASSWORD=$(sha256sum <<<"${CODE}${PASSWORD}")
clear && echo "typing"
xdotool - <<<"sleep 0.5 type ${PASSWORD::${1:-20}}aA@2"
sleep 0.5
echo "done"
sleep 1

The idea is that a user inputs a code related to the needed password (gmail, bank1, se-security, etc...a list of these could be stored in a file online or anywhere, as it's not a secret), and also a master password. (The command line argument truncates the password if necessary since some websites don't allow 24 characters). The script hashes the concatenation of these strings, and appends 'aA@2' to make password rules happy. It types it out (vulnerable to keyloggers, I guess?) rather than using the clipboard to avoid obvious problems with having a password in the clipboard.

So, my main two questions are:

  1. Is this idea (hashing a pw/code combo to get the "real pw") terrible for some security reason?
  2. If the overall idea is ok, is there any noticable security problem with my implementation?

Regarding question 2, I think I've covered the basics, i.e., no echoing the password as it's typed, and handing strings to sha256 sum and xdotool as stdin so that they're not cli arguments (which can be viewed using, e.g., ps).

Also, the reason for iterating through 1024 runs of sha256sum is just to make cracking slow (I don't think this can be parallelized...but I'm no expert). My thinking is that if someone manages to get one of the output passwords in the clear, I don't want them to be able to brute force my master password, even given the output, the algorithm, and the id code associated with the password.

I know there are key derivation hashing algos that do much of this already, but I don't think they'd be as common as sha256 (even any smartphone browser will to sha256 sum calculations, I think). I'm aiming for maximum portability/flexibility here.


Edit: I think I'm satisfied by that link (and others I've read) that the overall idea isn't too terrible, so I've struck out the first question. I'd still like more info about implementation.

  • 1
    Be very careful with such plans. You can make lots of mistakes that render such schemes vulnerable to easy attacks. Look at how password derivation functions are implemented. Do some research into Message Authentication Codes, too. Finally, 1024 rounds of sha256 are nowhere near enough slowdown. SHA256 is designed to be fast and there are hardware implementations! What's more, you should make that number configurable so that when CPU power increases, you can increase the number of rounds. This is easy to do; simply store the current number of rounds along with the resulting password hash. Feb 17, 2018 at 0:52
  • 3
    @Pascal You do not want to do rounds of SHA256, you want to do PBKDF2 rounds, which operate a little differently. Doing multiple rounds of a hash function opens you up to new issues.
    – forest
    Feb 17, 2018 at 4:54
  • @Pascal Is there a different hash function that would be better, that is as widely available? Also, I'm not storing the results. I need to balance between the time it takes to genrate the password on the fly, and the time per attempt for an attacker. Feb 17, 2018 at 8:30
  • @forest What issues? This is exactly the sort of info I'd like. PBKDF2 isn't installed on my machine by default, so I assume it's not as available as sha256. Is there an alternative that would be? Feb 17, 2018 at 8:32
  • @forest: I'm aware. I just wanted to point out that doing 1024 rounds of a fast hash function won't slow things down noticeably. Feb 17, 2018 at 9:42


Browse other questions tagged .