project idea: portable password safe

Ron K. Jeffries rjeffries at
Mon Sep 9 11:46:01 EDT 2013


I would be in target market for a password safe. A few comments:

>> A lot of my usage involves mobile devices. Not clear if you plan to
address that need.

>> Trusted PC required? Not what I'd prefer, but maybe it's what you have
to accept.

>> At the risk of being laughed off this list, there's a subset of
functionality I'd find VERY useful:
Password safe with keyboard and display.
Passphrase required to open safe, plus challenge response.
In a dream world, some form of biometric authentication.
The goal is to store passwords, and display password when needed. Period.
In other words, it remembers passwords I do not have memorized.

Yes, this leaves user vulnerable to keyloggers etc. What it does do is
allow for secure
storage of passwords.

Making the device tiny is not on my wish list, since I'd expect a decent
display e-ink?
and a keyboard large enough for human fingers, and with enough keys that at
a minimum numerals get a dedicated row.

A capability for the password safe to construct passwords would be useful.
If that was included,
needs to allow setting rules to affect the pattern so as to improve ease of
typing or human memory.

I suspect what I am suggesting is a different product from where you are
It's certainly a niche, agreed. But think about an aging population, where
a way to remember
decent if not NSA-quality passwords would be VERY useful.

ron k jeffries

Ron K. Jeffries

On Mon, Sep 9, 2013 at 8:16 AM, Werner Almesberger
<werner at>wrote:

> Felix wrote:
> > Wow, they're sooooo cheap! I said the LCD one because it has built-in
> > character display, so it's easy (at least for me) to interact with it.
> Everything is cheap in China ;-) The challenge is to find out if
> it also works ...
> > Also can be developed in the future a usb powered mcu with usb-host
> (again
> > for keyboad plug-in) and radio that will communicate with the device :P
> Regarding USB, there the the following options:
> 0) device only. This is what I drew in the block diagram.
> 1) unpowered OTG: constrains choice of MCU, but there are good and
>    inexpensive MCUs with OTG now, and it'll only get better in the
>    future. To attach a USB device, you need a Y cable that provides
>    power from another source (e.g., a PC) and you lose USB device
>    functionality while operating as host.
> 2) powered OTG. Add a boost converter for Vbat -> 5 V, but still
>    require a Y cable and external power source if the device we
>    connect draws more than very little. I.e., it would be fine for
>    pairing a dongle but not for some/most/all(?) keyboards.
>    A device that draws little power would be connected either via
>    the same Y cable but without needing an external power source,
>    or via a Micro-AB to A cable.
> 3) more power. Switch to a stronger battery, at least for keyboards.
>    Since a stronger battery (AAA, AA) has a low voltage,
>    a) the system would need to run a boost converter also while in
>       standby, or
>    b) we'd need to have two battery cells (yuck), or
>    c) we'd add a second battery (CR2032) for standby (so that the
>       MCU can listen for a wakeup signal and also maintain time).
>    Being able to maintain time would be desirable for any "code
>    token", e.g., TOTP (RFC 6238).
> 4) separate USB A receptacle. This considerably constrains the
>    choice of MCU or requires two USB-capable MCUs. Power could come
>    from
>    a) an external source, plugged into the USB device port. So the
>       password safe basically acts like a Y cable itself.
>    b) a weak internal source (or an external source).
>    c) a strong internal source (or an external source).
> 5) USB A receptacle plus dongle bay. This adds an empty space in
>    the password safe's case to transport an RF dongle. This was the
>    original proposal.
>    A purely mechanical bay could also be added to any of the other
>    designs, if there is room.
> So, assuming we want to use this with power-hungry devices, each of
> these solutions would require the following features:
> Feature required        0   1   2   3a  3b  3c  4a  4b  4c  5
> ----------------------- --- --- --- --- --- --- --- --- --- ------
> MCU USB                 dev OTG OTG OTG OTG OTG D+H D+H D+H D+H
> Y cable                 -   Y   Y   opt opt opt -   -   -   -
> AB Host cable (or Y)    -   -   -   Y   Y   Y   -   -   -   -
> External power source   -   Y   Y   opt opt opt Y   Y   opt see 4*
> Bigger battery          -   -   -   Y   Y   Y   -   -   Y   see 4*
> USB A receptacle        -   -   -   -   -   -   Y   Y   Y   Y
> Dongle bay              -   -   -   -   -   -   -   -   -   Y
> 1) would be an easy upgrade for the device-only design. People who
> are comfortable with the treacherous safety of their PC as their
> interface to set up the password safe and those who don't mind to
> do such things through a possibly quite clumsy dial-and-push
> interface would see no difference to solution 0).
> Those who want the extra security of using a "dumb" keyboard would
> be able to do that, but at the cost of somewhat messy cabling and
> the occasional hunt for a power source.
> Also pairing the dongle would require either trust in the PC, a Y
> cable, or the use of an over-the-air pairing protocol.
> I kinda like that for a first round. All the powered solutions
> that don't also include a second port still need fancy cables and
> thus don't really improve usability all that much. And the second
> port is a bit of a burden.
> Dropping the bay may have a usability impact. On the other hand,
> it decouples the mechanical design of safe and dongle, which is
> nice from an engineering point of view.
> > Agree with that. I remember to see a curious design in TI
> documentation[3]
> > using tactile sensors.
> I'm a bit wary of capacitive sensors. I did a design that runs
> from a unregulated battery, not too dissimilar from what we'd have
> here, that uses a small sensor through some 3 mm of acrylic and it
> performs very unevenly. But maybe it's just my algorithm that
> sucks. Should look at TI's :)
> BTW, their code [1] is under 3-clause BSD. None of that "use this
> only with our hardware" others are so fond of. Nice.
> Another drawback of having only a capacitative sensor is that,
> when in standby, the MCU has to wake up from time to time to take
> a sample and see if the user demands its attention.
> - Werner
> [1]
> _______________________________________________
> Qi Hardware Discussion List
> Mail to list (members only): discussion at
> Subscribe or Unsubscribe:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the discussion mailing list