2

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:

#/bin/bash
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}")
done
wait
clear && echo "typing"
xdotool - <<<"sleep 0.5 type ${PASSWORD::${1:-20}}aA@2"
sleep 0.5
clear
echo "done"
sleep 1
clear

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.

Thanks!

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.

mathemancer
  • 21
  • 2
  • 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. – Out of Band Feb 17 '18 at 00: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 '18 at 04: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. – mathemancer Feb 17 '18 at 08: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? – mathemancer Feb 17 '18 at 08: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. – Out of Band Feb 17 '18 at 09:42
  • @mathemancer: 1024 rounds of sha256 take you a long time if you call sha256sum in a bash script. But attackers won't do it like that - they'll call a single program that implements the sha256 algorithm (or calls a hardware implementation) and runs it in a loop. This will be so much faster than the way you're doing it that it's not even funny any more... and yes, there are several slow hash functions designed to securely hash passwords, bcrypt for example. But again, be very careful. Building your own crypto is hard. It almost never works, not even for the experts. – Out of Band Feb 17 '18 at 09:46
  • @mathemancer Re. issues, see https://security.stackexchange.com/q/53861/165253. Are you sure you don't have PBKDF2 support though? You may have support for it in a Python library, e.g. [hashlib](https://docs.python.org/3/library/hashlib.html). And just a side-note: The `clear` command does not wipe what is displayed on the screen, but merely "hides" it. You can still scroll up a little bit even in a regular terminal, despite being cleared. – forest Feb 17 '18 at 21:40
  • FWIW, this is not a new idea. The concept is called a _stateless password manager_, and there are many implementations available (some better than others). If you write your own, you should probably not write it in `bash`. – forest Feb 17 '18 at 21:44

0 Answers0