Security advice for USB password generator
Sam P wrote 01/25/2016 at 11:10 • 0 pointsI have this idea for a USB password generator which doesn't store any passwords. Instead it generates them as an when you tell it to from a master password that you type into the device using buttons on it. As soon as you unplug the device all passwords are forgotten.
The area I need advice on is the password generation. My initial solution is to concatenate the master password, username, website url, and version (to create 2nd/3rd etc passwords for websites), then calculate a SHA-256 hash of that string. With the output data I would then choose a suitable encoding depending on the website limitations (e.g. some are alphanumeric only).
Does this sound like a safe strategy? My main concern is if someone manages to obtain multiple passwords from different websites. It may be possible to work back to the original master password. Unfortunately the maths is a bit beyond me to figure this out myself.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
"My initial solution is to concatenate the master password, username, website url, and version (to create 2nd/3rd etc passwords for websites), then calculate a SHA-256 hash of that string."
This is OK, but you should add some salt before hashing - concatenate some additional random bits. They could come from some kind of internal timer/counter or ADC noise. With this, even knowing master password won't be enough to guess the website password.
Are you sure? yes | no
I've been looking a bit more for existing solutions, and what I have found a lot of are password generating websites such as http://www.hashapass.com/en/index.html
These websites take a string (e.g. website url) and your master password, then hash them together to generate a new password. This technique looks very similar to the salting that is often done when storing hashed passwords on web-servers. This looks quite promising as the USB password generator would only be storing the "salts".
Are you sure? yes | no
I wouldn't rely on the MCU not being reverse engineered. I've seen plenty of hacks of people getting around those protections to reverse engineer code.
Are you sure? yes | no
I have no background in infosec, but this is what comes to mind:
The hardware matters just as much, if not more than the exact algorithm you choose. What are you planning to use for the decryption/USB-keyboard part? If you pick something common, like a Atmel or PIC MCU, an attacker could just dump the flash, run it through a disassembler, and run the hash(es) against your own decryption code.
Some MCUs have security options that should block attempts to read their flash, but you may want to research and see if there are known exploits before you settle on a specific controller.
Think about what else an attacker could do if they got physical access to the hardware. Lets say the code on the device keeps track (in EPROM) of how many attempts have been made to guess the password, and locks the user out over a certain threshold. Does this still work if the hardware is reset at different points during the process? Is it possible to trick the controller into writing that count to EPROM/flash so many times that it wears out the memory?
Are you sure? yes | no
The idea was that the device never stores the password permanently. Instead you enter it through an interface (5 way tactile button and minature display is one idea), and the password only stays in RAM while it has power. As soon as you unplug it the memory is lost. It would store websites and usernames, but I consider that public information anyway.
Here's a (very) crude graphic of the device: http://imgur.com/sQkP9Cb
The interface would be similar to how you used to text on old phones except you'd use two pushes of the button per letter, one to select a group, and another to select a letter within the group. With 8 possible directions of the button that gives 8x8=64 combinations, enough for the alphabet and extra symbols. If I include the middle button too then that increases it to 81.
Are you sure? yes | no