Support typing passwords at system login screens

[nthdimtech]

It's desirable to have strong passwords for system logins where you wouldn't be able to run the client yet. This becomes a problem especially for a user who needs to have many such passwords and memorizing them all could be a burden. The challenge with this issue is how to address how to communicate to the device when you need to type a system password and how to add some level of security to the process.

[dumblob]

Maybe a long press until LEDs change color/frequency_of_blinking.

I guess we can support "infinity" number of passwords just by waiting long enough and showing the different situations with the built-in LEDs. Return to the default state will be done through a "double-click".

The configuration will be a table like the following:

constant press for N seconds	password	LED color or blinking pattern
2	abc	red
4	def	green
6	whatever	blue
8	yet_another	red+green
...

I've googled a bit one button control and it's always accompanied by an advanced visual feedback (usually a color raster display) with some menus/... Which is quite different from our situation, but let's think something out 😉.

[nthdimtech]

Two limitations : any light pattern will not be easily observable while pressing (your finger pad will be larger than the button) and the button has only a single color. Here is what I'm thinking off the top of my head

1. Numeric unlock sequence. Press X times, pause, press Y times, pause, etc. Once unlocked the light turns on and stays on
2. Password slot selected by pressing X times. The device confirms by blinking X times in response then you press and hold to type. Press and hold again afterwards to relock.
3. Press Y times to select another slot and repeat

One problem is that the firmware will need to know what keyboard layout to use. This would have to be coded into the flash somewhere ahead of time

[dumblob]

One problem is that the firmware will need to know what keyboard layout to use. This would have to be coded into the flash somewhere ahead of time

Usually these passwords are highly system-specific and therefore we could enhance the table with the layout we'll use:

monotonically increasing integer designating the password slot	password	keyboard layout
1	abc	deu
2	def	eng
3	whatever	cze
4	yet_another	deu

[nthdimtech]

A good point. I don't think we can afford to store every common keyboard layout on the device though so the will have to be stored as needed and in a space efficient way. The flash blocks are 2k and around 128 bytes of that is already used. I would only want to reserve 1k of the first block for this feature to leave room for other things.

…

On 01/10/2018 03:43 PM, dumblob wrote: One problem is that the firmware will need to know what keyboard layout to use. This would have to be coded into the flash somewhere ahead of time Usually these passwords are highly system-specific and therefore we could enhance the table with the layout we'll use: monotonically increasing integer designating the password slot password keyboard layout 1 abc deu 2 def eng 3 whatever cze 4 yet_another deu — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#22 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/Ad4tAI3JycGwq9Yvv8n3hLWwd3SndhQ_ks5tJUsogaJpZM4RZ-Xg>.

[nthdimtech]

Ah, it just occurred to me, there is no need to store the actual keyboard layouts at all. All the database needs to stores is for each password

1. The UTF-8 string representation of the password (for viewing purposes in the client)
2. The name of the keyboard layout (again for the purposes of the client)
3. The sequence of scancodes (with modifier flags) needed to type the password in the selected keyboard layout

This would eventually become less efficient for large numbers of passwords with the same layout but does a better job of bounding the the space needed if multiple layouts are used. There is also the benefit of simplicity, the keyboard typing code wouldn't be doing any translations or managing a list of keyboard layout structures, minimizing the amount of code space the feature would use.

[dumblob]

Definitely - that was the first thought after I read your post about missing space 😉.

[nthdimtech]

I've pushed an initial implementation of this feature in signet-base. I've decided on a different approach to user feedback than before. Instead of having the light flash to indicate the selection, Signet will type a character every time you press a button. When you do a long press it will type the password in the slot corresponding to the number of button presses (i.e. the number of characters on the screen). Before typing the password it will erase the characters pressed so all that remains is the password. If you don't press a button for more than 2 seconds the typed characters will be erased, resetting the process.

All that remains is the client side of the feature which shouldn't be too hard. I tested the firmware so far by simply backing up my device and adding in the passwords into the backup in a hex editor then restoring the backup.

[dumblob]

Sounds good to me - it's a very good idea of an intuitive feedback.

After it gets to the master branch, we shall not forget to update the documentation with a huge notice, that it shall be used carefully as it's actually a huge security hole as anyone with a physical access to the Signet can literally dump all the "login screen passwords" just by going through 1-N number of characters and acknowledging each of them. It also might be prone to your own misuse (it's easy to press e.g. once shortly and once at length and the password gets spit out disregarding where the Signet is connected and at which "state" is the user interface of the system).

Poor man's enhancement to this could be to set e.g. 20 dummy passwords and first the 21th one (not necessarily in this order!) would be the really functional one. Just to prevent quick brute-force physical attacks of unprepared persons (i.e. persons without USB packet reader) if the time would highly matter.

[nthdimtech]

It has got to the master branch on signet-base, it just can't be used yet since the client can't set the passwords yet. As it's implemented there are only 4 password slots each taking up 128 bytes.

Security could be implemented a variety of ways with the extra space left in the root block. Your idea could be implemented with a slot offset field and the unmapped slots could have passwords psudorandomly generated by the device. I think I would be happy with a numeric code sequence entered in a similar way as passwords slots are selected. If your unlock code was 142 then you would activate slot 1 then 4, then 2. After that perhaps the light would come on to indicate an unlocked state and you could select the slot for typing.

[dumblob]

If your unlock code was 142 then you would activate slot 1 then 4, then 2.

Yeah, I mentioned it just as an idea - it doesn't guarantee anything. Either way this "unlock code" of yours sounds good to me - for three numbers it would already be a little bit tedious to try all the 9^3=729 combinations by hand (or maybe even four numbers like bank cards giving 9^4=6561 combinations, but this might be already impractical).

We could even add a tiny delay (200ms?) between presses, so that no robot can press it quicker than an average person to prevent quick brute force attacks. The delay of 200ms would allow a (robotic) brute force attack on average in about 4m 25s which should be OK for this pseudo-security mechanism 😉.

[nthdimtech]

The client portion of this feature is now on master and I have tested it for awhile so I'm closing this. It will go out in release 0.9.11 which is coming very soon.

Regarding robotic brute force it turns out there is already a defense against this, although it isn't relevant yet. In case there is a noisy signal on the button the firmware will reject presses closer than 100ms together.

[nthdimtech]

Following up on signet-base #26. The most important thing I want to say is that I think the next release should contain one or more methods of securing the password slots. I wanted to get the feature out in some form first to get feedback and identify bugs. What I'd like to see is a user selectable security level scheme, the lowest level would be the current implementation, the next level might be a simple PIN system, and the most secure could involve something more sophisticated as @tuxlifan has proposed

[nthdimtech]

Sorry for moving things around so much, I forgot this issue was closed already. Instead of reopening it I have created a new issue #80. I think it's best to have a client repo issue even for things that require a firmware change because the issue is not fully resolved until the client can edit the data.