Holy cr*p guys… we were amazed by the quantity of positive feedback that was left in the comments section of our last article. We have been featured by Slashdot ! We got plenty of project name suggestions, therefore we organized a poll located at the end of this post to let you decide which one is best. I also received many emails from people eager to start contributing to this offline password keeper project. If you missed the call and want to get involved, it’s still not too late. You can get in touch with me @ mathieu[at]hackaday[dot]com. So far, we have many beta testers, several software developers, one security assessor and a few firmware developers. Next step is to create a mailing list and a Hackaday forum category once the project’s name has been chosen.
Obviously, the very first post of our “Developed On Hackaday” series was to gauge your initial reactions to this ‘new’ project. Notice here the double quotes, as when someone has a new idea there usually are only two possibilities that may explain why it doesn’t exist in the market yet: either it is completely stupid or people are already working on it. In our case, it seems we are in the second category as many readers mentioned they wanted to work/were working/had worked on a similar product. As we’re selfish, we offered them to contribute to this new device.
To ensure that all of our readers are on the same page as to how the device will work we embedded a simple block diagram after the break, as well as a list of all new functionalities that we want to implement given the feedback we received. So keep reading to see what the future holds, as well as to vote on this new project’s name…
As we don’t really need an ARM processor for this project, the only microcontroller we can use while keeping direct Arduino compatibility is the ATmega32U4 from Atmel. We haven’t chosen which IDE we’ll develop on (if we actually use one). The device will be recognized as a USB keyboard (USB HID class), therefore no drivers should be required on Windows/Linux/Mac/Android/any system you have. A few of our friends actually told us that Tablet PCs and recent phones can enumerate HID devices via their USB OTG port. We may use the great LUFA library from [Dean Camera] or the Teensy code from [Paul Stoffregen] for USB communications. The next post of our ‘Developed On Hackaday’ series will be about the chosen hardware so we welcome any suggestion from our dear readers in the comments section below.
As a few readers were worried that it’d still be possible to lose stored passwords with the proposed setup, we’d like to emphasize the fact that the device will be able to clone your smart card (containing your AES key and main email password for example). Obviously, it’ll only do so once the initial smart card is unlocked and will copy the same PIN code to the new card. Note that the cloned card is supposed to be kept in a safe place. We’ll also offer the possibility to export the encrypted passwords stored in the device internal memory (not shown in the diagram).
We previously mentioned that a browser extension will send the currently visited website to the device, so the user can approve the sending of his credentials by tapping the touchscreen. One very relevant point has been raised by [tekkieneet]: the fact that one user may always click ‘yes’ without checking that the website visited is the same one shown on the OLED screen. [Tekkieneet] would prefer making the user browse through all the saved websites’ credentials without using any plug-in on the OS side. In our opinion, that reduces user friendliness… what do you think? Could we come up with a way to force the user to check the displayed URL?
[Happyjam64] also suggested that we should force the users to switch passwords every few months. Would this become cumbersome for novice users? Should we allow the users to select what type of security they want? We’re obviously talking about trade-offs here.
Here is another question for our readers: how long should we unlock the smart card for once the user has entered his pin code? A short period may render the device annoying to use daily, and a long one compromises the security of the system. The Hackaday writers’ educated guess would be to force users to lock their computer when they’re away by removing the smartcard. The device would detect that the card is not here anymore and therefore perform a keystroke to lock the computer (what’s windows + L for linux and mac?). We’d just have to teach our acquaintances to lock their computer when they’re not in front of it (that seems reasonable, right?).
We look forward to reading your opinions of these key points, and we’ll see you soon in the next episode of our Developed On Hackaday series (thanks [Ren]). In the meantime, don’t forget to vote for your favorite project name!
What if the device could send you to the login page as well. So you can make sure that you log into the correct site.
What if the device could send you to the login page. It could act as another way to avoid the wrong site login problem.
Hey Nate,
we could place shortcuts on the mooltipass screen that’d take you to a particular page inded :)
Forced updating would make a nice option (configuration?), but as someone who already uses unique generated passwords for each and every password I have (100s) some of which I don’t regularly use, forcing me to update them at any frequency is gonna make Multipass more hassle than it is worth.
Could timeout length be configurable?
of course!
Linux Lock = CRTL + ALT + L
May only be Ubuntu
Linux Lock = CRTL + ALT + L
Ctrl-Alt-Del works fine on Fedora+Gnome ….
good to know! thanks guys!
It appears that Apple and Canon have both applied for the trademark to “Multipass” and its variant spellings. I personally wouldn’t bother with that one…
Bummer, but good point, thanks for researching.
How about “Mule-T-Pass” ?
I’d personally go with “mooltipass”.
Nice! This is how great trade names ate born.
brilliant!
we have a winner!
I just created the mooltipass google group, so you’re welcome to join: http://groups.google.com/d/forum/mooltipass?hl=en
Thanks [omegacs]. I’ll soon publish a new post about the mooltipass hardware.
;-)
Of course, if there’s any kind of company or brand created for it, you have an obvious choice as well… Then again, that might raise some issues with the production company or whoever, if they have any kind of trademarks.
“The Hackaday writers’ educated guess would be to force users to lock their computer when they’re away by removing the smartcard. The device would detect that the card is not here anymore and therefore perform a keystroke to lock the computer (what’s windows + L for linux and mac?). We’d just have to teach our acquaintances to lock their computer when they’re not in front of it (that seems reasonable, right?).”
I doubt as it is described would be very secure, I can think of all sorts of undocumented low level API’s in Windows to override keyboard hooks like Windows + L. The SMART card systems I’ve seen used with Windows use the in built SMARD card stuff inside Windows, rather than relying on a keyboard combo.
By “stuff” I’m referring to domain group policies, user authentication, active directory etc.
I think, what was meant by that, is more of an option to lock your workstation if you leave. This seems more like a convenience feature than an actual security measure?
What about letting the browser plugin wipe all cookies and password for the specified websites whenever the card is removed, instead of locking the workstation?
Hmm. That might get annoying, but I guess it’s really just personal preference here. I wouldn’t like that, say, on my home PC. Now on a friends computer this would be nice. You could just as easily have the browser do that, with or without the plugin. (Maybe not IE, it’s been ages since I last ran it) Most browsers should support clearing the cookies/not saving passwords/cache on exit.
My company made a keyfob-style password device with encyryption. The internal name for the product was “Lose it and you’re screwed”.
While the idea of something that saves/creates passwords and types them into a web form is a great start, I’d much rather work towards a device that actually negotiates directly with the site in question. Form a tunnel between the security site and the crypto device, where the web browser is just a conduit, and make that entire channel secure. Don’t know much about HID and whether it’s bidirectional and browser-capable, but from there you can easily create a bidirectional channel with the secure site.
The crypto aspects of this protocol are outside my area of expertise, but I would consider the ability to securely negotiate with a site *WITHOUT* trusting the computer and browser to be a major advantage.
Also, I’d use something like the at*X*mega32a4u, which has silicon AES and CRC engines. It also has a separate flash section with its own lock bits that could be used to store any device keys and code.
As far as helping out with the hardware/firmware, I can help with everything up to but not including the PC-side stuff, as I have time to do so…
The Xmegas with encryption requires an export license to be brought out from USA. I got this mail from E14 when I tried to order a handful of A4’s
Hi Mr Mats Engstrom
Thank you for ordering with you. I tried to call you but unable to reach
Please note that oc 2066309 required export licence. Lead time 37 working ays. Kindly please advise if to proceed?
Regards,
XXXXXX YYYY
Sales Admin Specialist
element14 (formerly Farnell)
Strictly speaking *anything* that does what I want to see (end-to-end encryption, from site to device) will require export documentation, whether it’s all in software or hardware assisted. I don’t consider that a point against xmega for this at all, if end-to-end is to be implemented at all.
Even this device as talked about here (with the mentioned ATmega32U4 chip and the encryption done in software) will require an export license.
One can always develop and distribute this entirely outside the old US
of A.
As for microcontroller, I would look at KL24P80M48SF0 as it is $2
cheaper than ATMega. Even making this in the 1k quantity, there is
significant saving. Can always port the supporting library to make it
“Arduino friendly” like the Teensy 3.1.
We touched a little (very little) on this in this series of comments: http://hackaday.com/2013/12/06/developed-on-hackaday-lets-build-some-hardware/comment-page-1/#comment-1124438
That opens up means for attacks, and as nothing will ever be secure, it doesn’t hurt to shutdown possible points of attack. Also, creating something that can be used without site/browser interaction would be the most useful if the custom encryption from the web designers isn’t adopted.
Also as I have pointed out, the usage should not restricted to _JUST_
web browser. e.g. You could encrypted yours HDD(s) with a long and
randomly generated encryption key and store it on the key.
As far as I am concerned if you trust web browser + plug-in or “Cloud”,
you might as well use the built-in password management on the web
borwser. Afterall, Google (Chrome), MS (Internet Explorer) and NSA
are still the good guys, right?
I like the idea of using it to encrypt (or generate a key anyway) the HDD. Perhaps profiles could be set up (seems this would be useful anyway) for different password schemes (lengths, allowed characters, etc)
Encrypting large amounts of data requires significant changes in the hardware, as you’d preferably want a very fast microprocessor (FPGA would be even better) to perform the encryption/decryption. USB 2.0 would also be a must. All in all, the final price would significantly be higher.
“You could encrypted yours HDD(s) with a long and
randomly generated encryption key” “using it to encrypt (or generate a key anyway)” Not looking to do the actual encryption, only generate a key.
Which begs the question: what will we be using for the key generator ? RNG algorithm ? Please tell me no double eliptical curve (for reasons well known by now).
I ask because of this: http://arstechnica.com/security/2013/12/we-cannot-trust-intel-and-vias-chip-based-crypto-freebsd-developers-say/
1. Manual or automatic selection of password? Configurable per password. Some passwords I care about (bank accounts, etc), others not so much (Chipotle online ordering).
2. Force password change after some interval? No, but provide the number of days since last changed on the display each time the password is used.
I agree. It shouldn’t force changes or if it does it should allow for setting custom expiration times for each and every password, beyond showing you how much time it has been in use.
Noted!
For users not checking the displayed URL – add something else to the screen that’s a function of the website.
Ideas:
– Background color
– OpenSSH-like randomart
– Put the “authorized” button in a different spot
– Patterns from a vibration motor?
The idea of removing the SIM card to lock the computer(Or device, if you don’t lock your home workstation) is a great idea. It settles a large chunk of [Tekkieneet] and I’s argument about timeouts/requiring a pin each time.
Switching passwords should be an option, not a requirement. This would be terribly annoying, if it were over something trivial like Facebook passwords (I don’t personally care if mine gets hacked, no real data there anyway.)
On the topic that [Tekkieneet] and I had such a heated debate: I believe, the password list should have the option of either user selected, requiring no pin if the device is unlocked, and/or require a pin for browser prompted selections. This of course should also configurable, in that you don’t want a pesky girlfriend deciding to copy your passwords into Notepad by going through the list (Turning off user iteration AKA unfaithful companion mode), or you really just want to be able to press the confirm button on browser prompting (Turning off pin requirement for browser prompting AKA what-was-the-point-in-buying(making)-this mode.). Of course, using both wouldn’t be a bad idea either.
As well as allowing the SIM card to be cloned should we allow the database to be read out so it can be backed up online on Dropbox for example?. You can then store the key seperately and be protected from physical damage or loss to both cards. It only takes a natural disaster to wipe out physical copies of anything.
From a user point of view:
Mandatory password changes are a royal pain.
Why not lock the device when the browser is closed, or shut down?
I have used Roboform for years, it allows user to go into a list of the manes of the accounts, then click on it. Roboform then will go to the site and enter user name and password. I think it is a good system.
Wohooo! and Bummer for the name :)
Another nice feature would be some kind of device filtering,for security purposes and maby “pswrd dump” feature to dump all the passwords in some situation,you never know when you’re gonna need one,and also what would be the method for write protection on the device?
My first two thoughts when hearing about this project:
1. It has to be very sexy/small in size to even consider using on a daily basis. Like fits on my keychain size. Otherwise for daily use something like LastPass (which I use and love) is a much better (and cheaper: free) option.
2. Please make this work as Bluetooth keyboard. My biggest pain with LastPass is their is no way to use it when logging into application on my phone like my Chase App, or when browsing the web with Safari or Chrome. Plus making this work over Bluetooth gives you the convenience of not having to plug it into a computer, you can even use it to lock the computer when you walk away etc.
Having to behave as a bluetooth means you would need extra firmware to
handle that protocol. It would now require a battery and that basically
means a Li-ion rechargeable battery. You can no longer use the postal
system to mail something with a Li-ion battery internationally.
So if the BOM parts comes to extra $5 and add in extra firmware work,
your bluetooth would easily bump up the retail price for $20 and
complicate things for distribution. Would have been a lot easier if you
forgo the “sexiness” and use a USB to connected it as a HID device.
not to mention the additional certification tests required…
What tekkieneet said + Do you really want to transmit your passwords over the air ? Yeah, I know, paranoia, but still …
“We previously mentioned that a browser extension will send the currently visited website to the device,”
Flip it around. Instead of the browser sending the current website, have the device send the browser to the login URL for that page. You could even have it auto-login for the user once the page loads. This way, the entire proccess is one action for the user, and much less vulnerable to social engineering.
I think the browser addon would also benefit from a community-maintained list of password requirements per website, including min/max length, allowed characters, and required characters would allow the most secure possible passwords to be generated. It could also look at the HTML of the password box to find the maximum length.
CAVEAT: Someone could concievably poison this list to weaken passswords. As a defense, the device (or add-on) should warn when generating a password below a specific entropy.
The issue of complacent users not checking the screen before clicking OK could be addressed by using a series of gestures on the touch screen rather than just a click.
I’m thinking 4 simple gestures: top to bottom, bottom to top, left to right and right to left. The gesture needed would be random each time and be shown on the screen with a simple arrow. .
Combine this with random positioning of the arrow on the screen and the user would HAVE to look at the screen.
Also, I generally hate feature creep but…
The hardware should be powerful enough that a later firmware can present the device as a PC/SC smart card reader and handle pass through to the card in the slot. The card in this case potentially being an OpenPGP card. The OpenPGP card would be a good choice anyway for the actual card given its longevity and (I presume) having undergone considerable scrutiny.
“force the user”
This is open, right? I’ll use MY device how I darn well please, thank you. Give me the option. Don’t “force” me to do anything.
Just my two cents though. This is still awesome. Go Team Hack a Day!
Instead of making the user interact with the device using the touchscreen for logging in make the device appear as a USB disk drive, the user would open the html file on the drive and select which website they would like to login to, much like the favorites page in chrome. Interaction via the touchscreen could be reserved for unlocking the device (so that it will appear as a usb disk) and for creating login credentials/verify certificates of websites at the time of account creation, as well as cloning the smart card. the device can generate the “Universal login page” on the fly once unlocked to prevent tampering with login page links, and javascript in the login page can even check that the DNS lookup is trustworthy before decrypting credentials.
I second the bluetooth keyboard idea for use with non-PC devices.
What about a optional integration with KeePass. This could be used as the store and you would never have to enter the master password on the computer again. Also would be nice to have a way to export the KeePass database to the smartcard for the first time. KeePass can already open up a URL and enter user and password. However it would still be good to send URL, username and password via a button press as HID keyboard if you are on a PC without KeePass. But I think if you use KeePass as a host application to manage the device and SmartCard you don’t need to redevelop everything from scratch. This also allows you to keep a offline database on a USB stick in your safe for example. I think this would solve many software issues quicker and your team can concentrate on the hardware development. I know KeePass is open source but I don’t know there team or developer.
+1 , why reinvent the wheel?
this device is clearly different than for example the anelok (see the nanonote mailing list) seen it’s not a complete offline solution. It would then make sense to use it as a “master lock” or “additional interface” to something like KeePass.
Hi this is really interesting. Could we store the site certificate fingerprint or such to device, that way we would not need to choose manually and we can trust that site is correct. for http sites(should not exist any with password authentication) we could have manual way by scrolling the list or accepting the delivered value.
However I am concerned about how easy it is to write a software that would act as browser plugin and deliver the site url or certificate to device. Could we have some pairing for plugin and dongle.
Hazam
Had been in actual fact searching for just an average shower enclosures during which
I stubled onto this site, didn’t even know there were such a thing as a ‘steam shower
enclosure’, wow, may just may have to acquire one