Developed on Hackaday: Let’s Build Some Hardware!

We’re pretty sure that most of you already know that a few months ago Hackaday was bought by SupplyFrame, who therefore became our new evil overlords. We do hope you’ve noticed that they’re actually quite nice, and in their divine goodness they recently gave the go-ahead on this series called Developed on Hackaday.

A new project will be made by the Hackaday staff & community and will hopefully be brought to the consumer market. For those who don’t have the time/experience to get involved in this adventure, we want to show and document what it takes to bring an idea to the marketable product stage. For the others, we would like to involve you in the design/development process as much as possible. Obviously, this project will be open source hardware/software. This time around, the hardware will mainly be developed by yours truly. You may already know me from the whistled platform (currently sold on Tindie) or from all the different projects described on my website, which makes this new adventure far from being my first rodeo.

What’s in it for the contributors? During all the steps of this project, we’ll offer many rewards as well as hand-soldered first prototypes of the device so you can start playing/testing it. Nothing is set in stone so every suggestion is welcome. Should we make a Kickstarter-like campaign to manufacture the final product, we’ll only do so once our prototype is final, our partners are chosen and all details of the production process are set and confirmed. In that case, we will just need to gather the required funds to make the device a reality. What are we going to build? Keep reading to find out.

So what about this new device? After many discussions with the writers, we decided we would make something useful for Hackaday readers. We wanted something simple that would simplify users’ lives and therefore settled on a secure offline password keeper. Keep in mind that the following description is just a draft, so your input is welcome in the comments section. Please keep it constructive as the way the comments are formatted is not optimal for this kind of discussion (we’re currently working on that).

The concept behind this product is to minimize the number of ways your passwords can be compromised, while generating long and complex random passwords for the different websites you use daily. As a side note, you may already know that most people often don’t use secure passwords, except red-haired women. Hypothetically, password keeping software could be circumvented by reading the key + encrypted passwords on the computer’s RAM. Ideally, the product should be so simple that my grand mother could use it (I’ll let you image her email password…). It will be as small as possible so it could fit in your pocket. Simply visit a website and the device will ask for confirmation to enter your credentials when you need to login.

What about the hardware? We thought a good solution was to make a device that uses a smart card, connected to your computer via USB (to keep costs low). The device will store your AES-256 encrypted passwords and the smart card will keep your AES-256 key (as well as a few other passwords). The smart card will be (for the sake of simplicity) a read protected EEPROM that requires a PIN code to unlock its contents. As with your credit card, too many tries will permanently lock the smart card. Therefore, the project’s main components will be: a smart card connector, a microcontroller (Arduino compatible?), an OLED screen and its touchscreen panel. The OLED screen will provide good contrast and therefore better visibility. On the software side, we’ll ‘only’ need to write a simple script running on the users’ browsers. The browser script will send the current website URL to the device (via HID reports).

We prefer a contact based smart card for several reasons. They’re much easier to source, are cheaper and can’t be easily sniffed without you noticing it. We hope that making this an open project will ensure any future problems are handled. We also want the device to be as hackable as possible, and an Arduino compatible device with a touch sensitive OLED screen and USB connectivity will surely interest beginners out there.

So what’s next? We need a project name, so please give us some feedback in the comments section. You can also directly contact me: mathieu[at]hackaday[dot]com if you’d like to contribute (we need designers, coders, webmasters…), be part of the beta tester team or if you already know potential partners for this project. We look forward to your comments!

Hmm, what if I lose the device? I’d rather have insecure passwords on all sites than risk losing them all if I lost the device / some idiot tried too many PINs. Maybe this can be solved by this project too (some backup solution), like off-device storage of the passwords+keys with a loooong password I can write on a paper (not on disk!).

As long as you can easily clone your passwords to another card which can then be put in a very safe place, that shouldn’t be an issue… Of course you’d have to make sure the correct pin is entered to do the cloning.

Do some homework on smart cards, modern types are basically uncrackable by anyone except for a very select few well-equipped individuals and perhaps some nation-state governments and even then it’s a slow, painstaking process.

Generating would be not be so bad if not for the fact that some of them
are so specific. “6 to 10 characters, and at least 2 capitals and
numbers, but NO symbols or underscores”. So by the time you specify that on the
user interface, you are not better than making up the password yourself.

I usually pound my keyboard a few time and add/remove characters to fit
the rule or randomly read a block of characters off junk food labels
from my desk.

Worked for one place that requires a unified “secured” password every
month or so, but for some of the systems, they can’t handle certain
characters. Of course they didn’t say which ones on the rules as it
would be so logical and user friendly. So after making up 10 passwords
later and I have forgotten my old password. :(

I like two factor authentication that involves my cell phone – it is something I am rather unlikely to lose, and if I lose it I can remote wipe it. Could this be added, as an extra layer of security? It could also mean that if a device is reported as missing that any attempt to use it could be tracked.

[I guess this system is already two factor authentication – card and PIN required – but having to talk to something online adds a useful extra level of security]

I only got as far as feature brainstorming / planning, and looking at datasheets on Microchip’s site. But I wasn’t able to really sit down and figure out exactly what features I wanted and what I could live without.

For getting the (username? and) password to the computer, I would honestly advise using a HID class device, and emulating keypresses. I don’t know much about USB hardware, but as a hobbyist operating system developer, I am well aware that this will simplify things on the software side. A lot.

That is not to say that no software will need to be written for the host computer. You will still need a way of getting the password to call up to the device itself. This won’t be easy, from what I can tell, because the system will probably need to store all passwords, not just ones for a web browser.

If a fake website were to report a different URI, or somehow get into the browser pug-in (which I agree is unsafe/insecure) Why would you then go about entering your pin? A simple glance at the screen would tell you the URI you’re authenticating against. Not to mention, if you made a script/plug-in that modifies the browser to, say, add a button that reports the URI to the device or validates the URI against a known list for automation it would make things more difficult to implement an attack. Your biggest concern is people themselves. Just like a ‘normal’ password on ‘normal websites’.

I don’t see how it could sniff whole password files if each one would require a pin, and no one is going to keep entering their pin without raising some questions. Which is why I said that people are the biggest security concern in this situation. Maybe I wasn’t clear in what I meant: The user of the device. Though it’s supposed to be pin based, not a simple yes or no, it still won’t account for stupid. Nothing will. That being said, it’s the same thing that could be accomplished by replicating hotmail.com at hotmal.com or My point in suggesting forms of automation was simply to appeal to a larger audience. This argument will get us nowhere unless you have a solution to stupid/inattentive people.

The device only cares about emulating a HID. KISS. No Plug-in, scripts
means removing attack vectors. The device has only one way communication
with the browser through the OS only.

It should only communicate with its host maintenance software after
authentication of both sides via encryption challenge/response.

The user scroll down a list of website names on _DIRECTLY_ on the
device, select the right one and press a button. Don’t automate that for
the user because it stops the user from thinking or taking
responsibility.

The user only have to unlock the device by a PIN once (with an optional
time out).

Entering PIN per website is annoying. Might as well has the users
typing in their own passwords.

I don’t see this appealing to anything more than a small niche group the way you describe it. While I agree that having a list, iterable by the user, on the device is about the best way to keep this secure, I don’t see a selling point other than to over-cautious computer geeks. This function should be optional, not the only way to access the device.

“Ideally, the product should be so simple that my grand mother could use it (I’ll let you image her email password…)” I don’t know your grandmother, nor anyone elses really, but if I were to try and design something for mine, most of the work would be cut out for them.

“The device has only one way communication
with the browser through the OS only.

It should only communicate with its host maintenance software after
authentication of both sides via encryption challenge/response.” – This is a good idea, but, I believe, flawed in that it would be more work to use it than to enter a semi-decent password, especially for people who aren’t computer/device savvy. Maybe a man-in-the-middle type of program would be the best way for it to communicate with the browser, but unidirectional communication would create too much work on the device side, creating a more expensive, less user friendly device. Also, using device for every login would be ultra annoying, most people just stay logged in, so you can assume it would only be needed weekly for some sites, perhaps daily for others. Using the URI and a browser plug-in is only an example, just the simplest way I could think to make this happen.
Ease of use, and integration sells better than what you believe to be actual security. Nothing is safe on the internet, this has been proven time and time again, and adding layers like this, while helpful, won’t stop stupid people from making stupid mistakes.

So lets say that we have a device, with one way communication. And you have to press the buttons to select your site, and enter a pin, which unlocks the device for say… 10 minutes (I’d say that’s a fair amount of time to not have to enter a pin, make it user selectable even depending on paranoia levels or work security etc) Why would I want this annoying piece of hardware? I can tell you right now, I wouldn’t buy it personally. Considering my parents or grandparents: I still wouldn’t. There is a slim chance I might make one for them. Probably some crap little .net program that runs on the PC to select their website and prompt them to enter their pin to go along with it. But expecting them to use it on a regular basis, would ultimately end in failure I think. Like UAC, it would become an annoyance, and eventually disabled/removed. I think the key to success here is: Ease of use, and a low cost. Perhaps a level of customization as well. Take a look at how places are starting to promote “One time passwords.” The idea, while very secure, is a pain in the ass. I don’t believe this type of security will sell unless promoted on a known, insecure network, and I believe something like what you outlined wouldn’t be much better than asking someone to type in their password.

This key stores your password and let you organize it the way you want
to not what someone else tell you to.

You enter the PIN _ONLY_ once until you unplug it if you are in a safe
place like home.

If you are at work and want it to lock itself if you leave your desk for
too long, you can set a timeout or want to take a chance. It is up to
you.

If they lock down PC at work, so you would have to login again when the
screen saver kicks in. So instead of unlocking the PC, unlock the dongle
with your own PIN. It can then be used to unlock the PC with the idiotic
password rules that the IT want you to use, but needed to be changed
every 7 days. IS that not an improvement?

So select an entry on the device, may it be an actual URL of a website
or a category or a text description. I think “your grandmother” would be
able to understand “My bank” much better than a string that say
“www.bankofamerica.com” much better. The user get to pick something that
he/she could associate not what the site owner nor a seemingly random
alphabet soup puke. That’s ease of use for non-geeks.

For the last time: URI is not user friendly PERIOD nor flexible.

Press a key on the device. No need to use PIN here as the device has
already been unlocked! (see paragraph 2 if you missed that) The device
would type in user id & password to the browser. It will be a one way
communication because your real USB keyboard won’t care about URI from
your browser either. KISS = Keep It Simple Stupid. What if you work PC
browser is locked down and won’t let you run your fancy plug-in?

There is only a single PIN to unlock the device which is the decryption
key for the whole password list. You have a 2 factor security – the
hardware that holds the encrypted data and the key stored in the
person’s head.

If your PIN is weak but easy to remember, that’s still okay as you need
actual hardware to get at the password list. The device could time limit
# of wrong password to cut down on brute force.

I have outlined more detail elsewhere in the rest of this topic. Not
going to repeat myself. The secured host software would provide an
alternate GUI than pressing small keys on the device. It is stored on
the device as a protected file and show up in the host as USB mass
storage device. If the user want to autorun it, go ahead. Let them
decide.

Lose the SIM if you ask me. Extra bit of hardware to buy, extra
connector and code to have to be secured. For something low volume like
this, factor in a BOM: retail price ratio of 1:5, the BOM should be kept
well below $10.

Yellow post it notes is as easy and cheap as they come. You easily can
do that at home for “your grandmother”.

If someone do have the user ID/password because you dropped in with a
post-it note of your password, they would still need to guess which bank
you are talking about because it is filed under “my bank” and not a
browser supplied URI.

I don’t believe you are reading what I am typing. As I said, a user iterable list SHOULD be there, and never did I sate a URI to be REQUIRED. It was used as an example only of a form of automation (as stated in at least one of my posts) but should be challenged every time by a pin. I understand fully what you are saying, but DISAGREE with the requirement of having to select everything manually, a browser plug-in should be an option, not a requirement. Period. As a device of this sort could be used for passwords not typed by a keyword (think bank pins or door security pads.) I will reiterate that the URI and browser plug-in were merely examples of a quick and dirty way of doing things. I suggest you at the very least read what I wrote and stop focusing on the URI example as I have over stated, it was just an example.

Neat idea, one I personally could use. It will be cool to see where this goes. This has some serious potential to showcase the mass of skill that is the HAD reader base. Your evil overlords havent been to bad so far. I suppose we can keep them.

+1 (sorta) for SOP… as in “S” “O” “P”, because I’d be more likely to not feel like an idiot saying the acronym than pronouncing it like the word “sop”. But we spell it phonetically, “Essopee”. Unique, rolls off the tongue; of course, it has “pee” in the name, so maybe not. :)

Actually there is no need to store the actual pass, if its used a derived pass like site_pass=function(pass,user,site,private_seed,shared_seed), in this case is possible to make even weak passwords act like a strong password.

Assuming that your hash function would customize the quirky password
rules for each of the website e.g. password longer than 6 characters but
shorter than 8, at least one uppercase, one symbols but not * or ‘ or _
on a full moon and it cannot be the last 10 passwords you used here..

I think having a password generator on the device where you feed the host-side software a set of rules about the password and it then asks the device to generate a password meeting those criteria and can then enter it into the registration/change password form would be great. Would make it easy to have high-strength unique passwords for every web site (and to change them if the site is compromised)

I like the idea of USB HID for the output of the device. Coming up with a way to talk to the device (e.g. loading new passwords) that doesn’t require specific drivers (maybe find a way to leverage an existing USB standard like mass-storage for this) would be great too. That way, it will work on any platform that the userspace software can be ported to and can be used even if you dont have the ability to install kernel drivers.
Heck, since its going to need flash memory for holding the password files, you could use the same flash memory to hold the userspace binary for your OS of choice, expose it over mass-storage and run it directly from the device, i.e. no need to ever install anything on the host PC.

Open source libusb-win32 work quite well on Windows as a signed kernel
driver. The calls are cross platform and can be used on a lot of
compiled/scripting languages.

All you need is to have a minimal set of control on the device itself so
that it can be used on a locked down or untrusted environment as a fake
keyboard and nothing else.

On a computer that you have full access, you can run the maintenance
host side software stored directly on the device and show up as a mass
storage device.

As far as I am concerned, host software should be written in native code
and not rely on bloated cross platform frameworks/script
languages/runtime environments.

My usual Window GUI is written in C and it can talk to my USB devices
with vendor specific commands. EXE file is around 150kB with all required
libraries statically linked in. My old Borland C stuff is around 100kB,
but the compiler won’t run in Win7 x64. :(

This makes me very happy that you guys are doing this…Would like to see it evolve to an extremely hardened device preferably not w/ a USB port. Maybe the PW just scrolls on a simple LCD and keyed in w/ buttons that scroll thru characters. Regardless this is a start. Still in school but will want to contribute when I can in the future. So awesome.

Those little OLED touch screens can get quite spendy (Especially without a decent supplier, I’d hate to be the guy sourcing parts from eBay in large quantities >.<) How about a regular OLED screen, or 16×2 LCD, and a capacitive touch module?

While I half agree, as I would prefer a device as small as possible, and as clean as possible, I also think that price should be taken into account. Also, we may appeal to a larger audience if it were navigable by, say, someone who has impaired sight? Just a thought really. If it were for myself, I would have an OLED touch screen, but if it were for a parent or such, I would have a keypad or capacitive touch pad.

This looks really awesome, and would certainly make my pasdwords a little safer. Right now, I’m using the same password everywhere with only slight differences (my havkaday password would have HaD at the end of it) or incrementing a number at the end of the password for those that need to be changed every month.

A minor problem is that I’m pretty sure some less educated bosses won’t allow you to plug in a device with “hack” in the name, or with a skull logo in fear that it injects viruses or something, thinking that hacking always means stealing private information. They might be even more concerned when they see the device automatically and instantly type in passwords.

I don’t have any suggestions to solve this problem, but you should try to make it clear that it’s not designed to crack passwords, only store the ones given.

I think the List of OTG supporting devices is not very long, but some popular phones are there – is there spevial software needed to make a HID-Device working on such a phone ? aka is it complicated to use ?

I would offer to have a look over the mechanical (case) design and made it ready for production – injektion-molding at protolabs ?

I’m glad you raised this point. A few friends told me that tablets and popular phones enumerates USB HID devices so we should be good to go! Please send me an email regarding the case design… we definitely need someone for this part of the project!

On android there is a possibility to have a separate keyboard. One could have a “keyboard” which reads a qr code (or maybe something through the sound plug or light). The password don’t have to go into the clipboard (probably safer) and it can be encrypted (maybe you could use RSA for key exchange and pairing, with an on-screen verification text too).

Coupling this with a (built-in?) thumb-print (or finger) scanner would remove any pin# requirement or failure modes, other than being forced to “thumb” the print reader. Or, perhaps one could use both a pin# with the thumb scan. The uniqueness of everyone’s fingerprints could be used to generate any encryption seed(s). Having the thumb (or finger) print scan be somewhat hidden, might make it more secure as well.

Any chance for a linux compatable device, or is this another windows only option? (I hate when that happens!).

It might be a thought to use microSD cards to allow large amounts of (encrypted) personal data as well. If interaction with a web browser is part and parcel, then having bookmarks accessible would be a nice feature, IMHO. Storage of, and access to, various web-pages would be nice, and given the huge microSC cards available, why not? Perhaps even have a USB port, to allow decrypting an external storage (thumb or hard drive?), on the fly, might be good to have as well?

This is a wonderfullly good idea, as password requirements are getting more difficult for humans to remember … and carrying around a “cheat-sheet” defeats the whole purpose.

My experience with fingerprint readers is far from being great… do you know some good brands? how expensive would one be?
The device will be USB HID so no worries for linux compatibility. uSD card is a great idea, but i’m a bit afraid that it’d take a while to encrypt large amounts of data given a cheap and small platform. Perhaps we could make another version especially dedicated to encrypt documents?

“…while generating long and complex random passwords for the different websites you use daily.”

Since you will have random generation and a bulk storage device, why not add the ability to make files filled with random bytes for use by one-time pad encryption applications? That might be an additional selling point.

One time pad is only as strong as how “random” your pad data is. Having
the One Time Pad generator on an Open Source project that gives away the
source code for the algorithm kind of reduce the security.

I would rather take a very large compressed file that is widely
distributed on the web and no one would suspect if myself and the other
person were to download it. e.g. a 30GB game download and use that as a
basis for a OTP. I would skip around the bits in that large file based
on a pseudo random function to make my one time pad.

While I’ve not heard any recent security holes, the Java programming language should not be used.

The device should be able to functiion without a JVR installed on the computer, otherwise you are leaving a lot of Java cons out of the market.

In addition, the device should be able to enter a password on a webpage without the user having to install anything on their computer for the purpose of using the device.
A keyboard emulating device such as HID as previousely mentioned should be able to do that.

Hmmm, one should be able to implement this from a usb drive using software installed on the USB drive. Run a virtual keyboard from the drive and have a desktop icon running similar to FDM’s (Freee Download Manager) desktop icon that issues the command to enter user name and password for the website.

A pop up window could be used to select the given website for password entry.

One thing that will be crucial as already mentioned, each entry will need to have it’s own editable password format rules. Editable becuase you know how developers like to change things for the sake of chainge, even if it does mean you can no longer access new messages that are sorted into folders as Yahoo’s most recent change has accomplished.

I liked the concept of using my phone to lock and unlock my computer via blue tooth automatic as when I am in range aka at the desk the blue tooth link causes my computer to unlock but get a few feet away and it automaticly secures itsself until my return, so how about some combination of the two use the secure card to store encrypted passwords and ID (possibly payment info, shipping address) and be basicly left in the computer it serves only removed to use at other PC’s I own or am a registered user of or my laptop when I go “road warrior”, the secure card data needs the blue tooth of my cell phone to be in range and possibly some part of the phones bluetooth ID encorperated into the encryption /decryption key for the secure card then I get a safe bulk storage of my password and id information and automated and secure presence required security the benifits being limited trasmital of the private key , the gaurded data, automatic operation, minimal card insert reinsert every time I leave my PC for a few because without the bluetooth signal of my phone the data is useless. The card then only gets inserted at work in the morning and if forgoten at work no biggy the janitor cant see my new design for a robotic custodian as since I have my cell the passwords are still secure. when traveling the card goes with and I keep internal office type security when I am in the feild.
Blue-wonder-Secure –“The Robotic Security interlock” is My market ready name suggestion, as minimal added HW would be required it would be fairly easy to launch updates and profit margin large as the expensive parts are the blue tooth PC device a card reader and a secure ANSI data card, 98% off the shelf and the real gem would be the programs and phone applications software required to implement the idea. What do you folks think??

Personally, I would want a device that plugs inline with my keyboard and listens for a particular ALT numpad code.Then I type the name of the website I’m on and it populates the password. I know that this doesn’t fit the vision of this project, but that’s just my 2 cents. Come to think of it, I might start working on this sort of thing myself.