Remembering passwords is a pain, and there’s a number of devices out there to make it easier. If you’re looking to roll your own, this guide to building a Final Key will walk you through the process.
We talked about the Final Key before. It’s a one button password manager that encrypts and stores your password. It acts as a virtual serial port for configuration. When you hit the button, it becomes a keyboard and types in the correct password.
The creator has no intentions of making this a commercial project for a number of reasons. Instead, easy build instructions are provided based on the Arduino Pro Micro. The 24LC512 EEPROM can be soldered directly to the Arduino by bending out the DIP legs. A few resistors, a button, and an LED finish off the project. The last step is to fill it with hot glue to prevent tampering.
The Final Key firmware is available on Github, and the case can be ordered from Shapeways. If you’re interested in hardware password management, you can also check out the Mooltipass which is being developed on Hackaday.
[Thanks to Lars for the tip!]
These little password keepers looks handy , but i have never gotton to build one. Instead i formed my own method of remembering passwords http://oorspronklikheid.wordpress.com/2014/04/03/how-to-make-awesome-passwords/
/”end shameles plug”
that’s a pretty neat idea; i like it! I just like to use sarcastic phrases. If anyone ever asks me the wifi password, I just say “I don’t know.”
I like [oorspronklikhied]’s basic idea, but their example algorithm only barely passes muster, and nothing guarantees that passwords are sufficiently distinct from one another that one compromised password wouldn’t make other passwords easy to crack. For the best case scenario (where password 1 and password 2 have 6 non-adjacent characters that are different) this isn’t too bad though.
The example password is made by combining 2 of about 2000 random English words, and then substituting 3 of ~46 random letters/numbers/symbols in the middle somewhere. To crack any given password without knowledge of another would mean working through 2000^2 word combinations, and 46^3 variants of each, with 6 possibilities for where the variant could start. 2000^2*46^3*6=2^41=41 bit password. That’s a bit on the low side, equivalent to a completely random 6 or 7 character password (depending on what characters are allowed). Adding a 3rd random word to the base word, or adding several more digits to the random characters in the middle, would improve this substantially. Unfortunately, I can’t think of a good simple way of guaranteeing that it won’t be completely trivial to guess another password once one is compromised. Anything is better than nothing against a unprofessional hacker with an old PC, but you can’t really guarantee anything until you have unique 64 bit passwords (10 or 11 completely random characters).
I’ve been thinking about this sort of thing a lot recently, and would be curious if anyone has ideas that could improve on this method. I’m not a cryptographer, but diceware seems to be about the best option for generating memorable passwords like CorrectHorseBatteryStaple. PasswordCard.org is a neat concept, but has a lot of potential vulnerabilities if you use the online card generator instead of generating your own.
There is also the apg (advanced password generator) tool for linux which allows you to generate phonetic passwords using a rather high degree of entropy.
What’s the benefit of this over something like software-based 1password ? A key sniffer would still get the input from this device. If anything this is more dangerous because at least 1Password tries to make it harder for keyloggers to steal your pass.
I agree with they key sniffer part. Maybe it could also act as a mouse to type in the password using the on-screen keyboard.
I have been “working” on my own version of this (if going nowhere is “working”) and plan on using a small ir remote wired to act as a keyboard for entering a pin. I would use this pin to act as a seed for the password.
Not perfect, but better than what I actually do now.
Check out the entropy lib if you are using an avr, it’s a basically turning the avr into a hardware random number generator, I it is what is used in this project too: http://hackaday.com/2014/02/10/the-two-component-random-number-generator/
And its entropy is well documented as being suitable for cryptography.
The benefit over this compared to a software based solution is, that the encrypted database of passwords can not easily be obtained by an attacker, with an on-computer solution, your database could potentially be stolen and then the attackers would have all the time in the world to brute at it, and you would never even know it had been compromised. Even if you get the master-password, which is obviously possibly using a keylogger, no matter the security system, you need to dump the eeprom, which requires physical access to the device, because, even if the device is logged in, you need to press the button on the device to start dumping. I’m not claiming that this is secure every possible attack, I don’t believe anyone dare make that claim. But if anyone can suggest an attack-vector, I’d like to hear about it so I may improve my idea, possible physical and software-based attack-vectors are relevant also to the mooltipass device.
> The last step is to fill it with hot glue to prevent tampering.
LOL. WUT? Please don’t give anyone stupid ideas about security.
This device is only ‘secure’ as long as you never let anyone else touch it and never plug it into a untrusted computer.
I think the point is that the tampering would be final. Not unpleasantly ongoing :)
But then one could easily “peel-off” the hot glue very easily. Probably a clay epoxy would be better.
No matter how well you physically design something, someone will always be able to break into it, even battery backed devices which uses a killswitch (like some credit card terminals) have been trivially opened without damage to the stored data. But again, the hotglue is there simply to hold the thing together and made it sturdy enough that I can carry it with me in my pocket without worrying, which i have been doing since I made the first one.
@Erinn
I think Eirinn’s point is that if anyone has access to it for long enough that disassembling it is even worth considering then you have sooooo many bigger problems. Talking about securing it against physical tampering is at best masturbation and at worst a dangerous amount of false security.
Not all tampering is a high tech reverse engineering attempt. Sometimes its just someone with a paper clip.
You are right that the device has not been protected against physical tampering, except for the fact that in the end, after you’ve succeeded in extracting the encrypted database, you end up with exactly the same level of security that any software-based solution provides. Also, simply “plugging it into an untrusted system” is not enough, you are only exposing the passwords which you actually play back, and, I should remind you, this differs in no way from the kind of exposure you would do by manually typing your login into such a system. Please, at least read the articles and source code before making claims.
“The last step is to fill it with hot glue to prevent tampering.”
No last step is to use something stronger to “prevent” tampering. Hot glue doesn’t even slow down a plastic butter knife.
thin epoxy bedding, then two strips of steel (spring steel if you want it strong) then finish off with colored epoxy. to get it apart you will have to destroy it.
Greetings, I made the Final Key, and would like to address some of the comments about security, best I can, if I am incorrect in my assumptions, please point this out.
1. Tampering:
The hotglue is not to prevent tampering, it is to provice mechanical stability and some amount of water-proofing.
The hotglue can in fact quite easily be removed, I have done that with a device where I made a mistake, I used a hot air gun to melt it away, a bit messy, but the AVR survived :)
2. Using in untrusted computers.
a. It is not possibly by any means to extract passwords from the device without pushing the physical button, so only the played-back passwords will be stolen, this is in contrast with an on-computer software solution where anyone with access to the GUI will be able to steal all passwords.
b. Unless you keep the arduino bootloader on the device, there is no way of tampering with the firmware without physical access.
3. Extracting passwords from the device.
a. If you disassemble the device and read out the eeprom, you will have an encrypted file, You need to break into that file before obtaining the passwords, every entry has it’s own IV to prevent from similar names/passwords/emails providing an attack vector (what adobe did not do).
b. This is the same level of secutiry as any good software based solution, except for the additional fact that you need physical access to the device.
c. There is even a tool available for people to backup/restore their password database, this is a builtin feature, the resulting file is a copy of the eeprom + crc checksum every 32 bytes. That file is thus, encrypted, but should ofcause be stored in a safe place, I’m using this feature to mirror my database to another Final Key, in case the first should die.
An additional note about password-generation: I am using the Entropy lib, which is taking advantage of the jitter of the watchdog timer to generate random numbers.
I’m still waiting for the owner to address the issue I discovered though: https://code.google.com/p/avr-hardware-random-number-generation/issues/list
The used board is a (Sparkfun) Pro Micro and not a Arduino Micro as linked.
I’m actually using 3 different boards, including a sparkfun, they’re all compatible.
Granted I didn’t read everything on the linked page (there’s a lot of it) but at first glance it looks rather cumbersome to use? If you’re on windows you first need to install the Arduino driver for it, provided you’re allowed to do it on the computer you’re using. Then you have to figure out which port it is on, open up putty (or download it first), connect to the device, find the pass you want and then finally press the button on the device to have it enter it on the page.
Doesn’t sound like something I would want to use. But of course I might’ve misunderstood how it works.
You are right about the convenience of installation on windows, that’s how windows is, it does not ship with the required drivers, so they need to be installed, that’s how using new hardware is on windows. But it would be quite easy for someone who use windows, to create an installer which could also autodetect the port and create a putty config.
However, Linux and OSX already ship with the drivers, so on those systems it is very convenient to use. I have thought of implementing a usb-mass-storage device in it so that the drivers would always be available, but I’m almost never using windows, and it already works fine on those few windows machine I do use, so I do not plan to investigate this further.
The mooltipass could potentially have a mode where no drivers are needed at all, since it will implement a complete user interface on the device itself.
I have thought of extending FinalKey to support bluetooth, this way, an android app could act as the interface, and thus eliminate the need for driver installation or serial-access on any computer (apart from also allowing the device to be used with android ofcause).
About 3 years ago I made AnyKey. Only used 1 micro being attiny85. Mine can also be re-programmed using usb-hid and acts as keyboard when button is pressed. Less parts, cheaper. And does what finalkey does. I patented it in belgium but never got the funding to mass produce:
https://www.youtube.com/watch?v=aCeOeqHbQeM
Maybe I should just go open source + open hardware?
Cool! ^_^ I am surprised you could get a patent it, I mean, it’s an obvious thing to do, I was surprised that no commercial product was available. It’d be interesting to see your code :)
I have a question about it though, how did you select which account to use? or does it require you to use the same password for every website ?
By the way, I’m interesting in learning more about the security of my implementation, so I’ve put up a little challenge, for fun, where I will send a free Final Key to the first person who can break into it. http://cyberstalker.dk/finalkey/hacking/