2FA on new hardware?

311 views
Skip to first unread message

Chris Huitema

unread,
Aug 23, 2016, 7:28:22 AM8/23/16
to mooltipass
I know its been asked before on the original Mooltipass, Do you think it would be possible to add 2FA support with the new mini? maybe as a stretch goal?

I have found a few basic implimentations based on an arduino, https://github.com/damico/ARDUINO-OATH-TOKEN and a good explanation here http://www.lucadentella.it/en/2013/09/14/serratura-otp/

Is there a RTC built in on the new hardware? if not could the app send the time/date to the device? or have a way to quickly set the time on the device for offline use

Would it be hard to save the "secret" the same as a password in memory, then just have a little function to generate the 6 digit code similar to the function that decodes the password normally? 

the app could have a screen capture thingy added to scan the barcode to get the secret, or option to enter the code manually same as most apps like authy do.

Anyway just thinking aloud here

Cheers,
Chris

Jeroen Massar

unread,
Aug 23, 2016, 8:02:57 AM8/23/16
to Chris Huitema, mooltipass
On 2016-08-23 13:28, Chris Huitema wrote:
> I know its been asked before on the original Mooltipass, Do you think it
> would be possible to add 2FA support with the new mini?

If you are starting out in the 2FA world, go for FIDO U2F:

https://en.wikipedia.org/wiki/Universal_2nd_Factor
https://fidoalliance.org/specifications/overview/

This is the way to properly and easily do 2FA.

The mooltipass is still very useful, as it will be the other factor: a
password.

And as it cannot be read out, it is a perfect one for that component ;)

Greets,
Jeroen

mathieu...@gmail.com

unread,
Aug 23, 2016, 11:47:39 AM8/23/16
to Jeroen Massar, Chris Huitema, mooltipass
Hello everyone,

Regarding U2F, FIDO U2F is indeed the way to go... it's too bad very few websites support it.
As Jeroes mentions (if I'm not misunderstanding you) having one device for passwords and 2FA partially contradicts the core principle of 2FA (as both authentication methods would reside on one single device).
We could however imagine in the future a dedicated firmware running 2FA functions only.

Regards,
Mathieu


--
You received this message because you are subscribed to the Google Groups "mooltipass" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mooltipass+unsubscribe@googlegroups.com.
To post to this group, send email to moolt...@googlegroups.com.
Visit this group at https://groups.google.com/group/mooltipass.
For more options, visit https://groups.google.com/d/optout.

Jeroen Massar

unread,
Aug 23, 2016, 11:57:06 AM8/23/16
to mathieu...@gmail.com, Chris Huitema, mooltipass
On 2016-08-23 17:47, mathieu...@gmail.com wrote:
> Hello everyone,
>
> Regarding U2F, FIDO U2F is indeed the way to go... it's too bad very few
> websites support it.

Most are waiting for full support in browsers. With only Chrome having
it native and people still using good old Firefox, it will be a bit of a
wait till Firefox has it for it to become a better standard.

Adding FIDO U2F support to sites is easy though, have been doing it
myself for a while already, but we combine both token + password, not
only the fingerpress like for instance Github does (though they ask for
the password when changing/deleting things etc)

> As Jeroes mentions (if I'm not misunderstanding you) having one device
> for passwords and 2FA partially contradicts the core principle of 2FA
> (as both authentication methods would reside on one single device).

That is indeed what I am saying.

> We could however imagine in the future a dedicated firmware running 2FA
> functions only.

That would not make it 'two factors' really. As both factors come from
the same device.

That is similar to a bank who thought sending two SMSs to the same phone
number was 'more secure', or worse: that asking for your 'security
questions' was a 'second factor'.

The idea of two factors is that one has to have one factor in the head
and another in physical form. Need to steal both to have access.

Effectively a combo of a 2FA token (be that HOTP ala Google
Authenticator) and a password storage device (ala Mooltipass) would defy
that already though; but at least they are physically separate and when
one can take both tokens (and the PIN in the mooltipass), then well they
likely will be rubber hose cryptoanalyzing the person already anyway ;)


The primary reason for keeping the factors physically distinct though is
that a compromise of one part might not affect the other (except for the
breakin case that is).

Having the PIN on the mooltipass is thus extremely important, as likely
one leaves the devices lying on the same desk or store them in the same
bag while traveling. That way, they will have your U2F token, but the
mooltipass is useless till they ask you politely for the PIN.

Greets,
Jeroen

mathieu...@gmail.com

unread,
Aug 24, 2016, 5:24:16 AM8/24/16
to Jeroen Massar, Chris Huitema, mooltipass
Hello Jeroen,

>> That would not make it 'two factors' really. As both factors come from
the same device.
I technically agree with you, but one would argue that the firmware is different enough so that isn't a problem (keeping in mind it'd be U2F firmware for a mini without password recall capabilities).

Cheers!
Mathieu

Jeroen Massar

unread,
Aug 24, 2016, 5:27:36 AM8/24/16
to mathieu...@gmail.com, Chris Huitema, mooltipass
On 2016-08-24 11:23, mathieu...@gmail.com wrote:
> Hello Jeroen,
>
>>> That would not make it 'two factors' really. As both factors come from
> the same device.
> I technically agree with you, but one would argue that the firmware is
> different enough so that isn't a problem (keeping in mind it'd be U2F
> firmware for a mini without password recall capabilities).

If I understand correctly, on your desk, for the auth to work you would
have 2 physically distinct devices:
- mooltipass mini -- password safe (PIN locked)
- mooltipass mini -- u2f

That would satisfy the 'two factors' quite well IMHO.

If both are the same device, it mostly too actually, especially as one
still need to have the PIN to unlock the password part.

As noted before, rubber hose crypto can't solve physical attacks ;)

Greets,
Jeroen

mathieu...@gmail.com

unread,
Aug 24, 2016, 5:29:31 AM8/24/16
to Jeroen Massar, Chris Huitema, mooltipass
Hello Jeroen,

If I understand correctly, on your desk, for the auth to work you would
have 2 physically distinct devices:
 - mooltipass mini -- password safe (PIN locked)
 - mooltipass mini -- u2f
>> That is correct.

Mathieu

Chris Huitema

unread,
Aug 24, 2016, 7:10:59 AM8/24/16
to mooltipass, jer...@massar.ch, chris....@gmail.com
the best thing about the Mooltipass is it overcomes the shortfalls of now, it remembers the few dozen passwords we all currently need (and it does really well)

and while i do agree that adding Fido u2f to sites may be easy (well over my head to be honest!), many haven't yet and the majority (more than 80% of the accounts i have) don't even have 2fa. 

I have enabled 2fa on every account i can, and currently use my phone to provide 2fa, and it works well but I'm really concerned about all the vulnerabilities with such a device that i use for everything, that is exposed 24/7 to 3G/4G, BT, NFC, WiFi + whatever other ways it could be compromised

So yes having the Mooltipass do both password and 2fa may be slightly less secure, at the end of the day its still 1) a device someone has to have 2) a card someone has to have, 3) has a pin someone needs to know 4) someone has to know how to use it and which login is for what account. so i would feel much happier knowing its offline 95% of the time and has very limited attack vectors. and to me is 4 factor. and a lot lot safer than my old street name and pet

If the same device could be used for both then people could choose how secure they want to be? if they want one device just for passwords and one for 2fa/u2f then they can set them up that way, or one device for everything (I personally want one for work and one for play) 





Jeroen Massar

unread,
Aug 24, 2016, 7:32:11 AM8/24/16
to Chris Huitema, mooltipass
On 2016-08-24 13:10, Chris Huitema wrote:
> the best thing about the Mooltipass is it overcomes the shortfalls
> of *now*, it remembers the few dozen passwords we all currently need
> (and it does really well)
>
> and while i do agree that adding Fido u2f to sites may be easy (well
> over my head to be honest!), many haven't yet and the majority (more
> than 80% of the accounts i have) don't even have 2fa.
>
> I have enabled 2fa on every account i can, and currently use my phone to
> provide 2fa, and it works well but I'm really concerned about all the
> vulnerabilities with such a device that i use for everything, that is
> exposed 24/7 to 3G/4G, BT, NFC, WiFi + whatever other ways it could be
> compromised

And the point of 2FA is that it is irrelevant that a single token gets
compromised. You need both Factors to successfully authenticate.

If your phone gets stolen/hijacked/hacked etc, it does not matter, as
they still need your password.

Also, 2FA tokens are single-use/time dependent, thus re-use is not possible.

> So yes having the Mooltipass do both password and 2fa may be slightly
> less secure, at the end of the day its still 1) a device someone has to
> have

Like your phone that you carry around, if somebody is close by they will
be able to take it, just as well as they would be able to access it over
the connectivity you allow.

And as the mooltipass is shiny they will take it and then figure out it
needs a PIN which makes it useless. (which FIDO U2F tokens do not have,
but, for those you still need the second password).

> 2) a card someone has to have,

Do you unplug it and store it separately in a secure place?

What if you travel? Put it in two bags that thieves steal together?
(In that situation I keep the card on me, while the reader goes
elsewhere; though often it just stays in a safe ;) )

I know my bank token always has the card inserted... this as when
somebody gets into my house, they also have the option of politely
asking me for the details (read: rubber hose crypto).

> 3) has a pin someone needs to know

The PIN is a great part of the mooltipass.

Though, has it been fully tested against automated testers ala an iPhone
(which has amazing security properties btw).

Android 'security' is just a farce though...

Check:
https://developer.android.com/about/dashboards/index.html

wow, Marshmellow has a full 15% of the market already, even after being
a full year on the market. Lets see how low the percentage will be for
Nougat now that has been released recently to select devices.

4.4 KitKat is from 31 October 2013, thus almost as good as 3 years old.
70% of the users are still on that all affected by StageFright and many
many other remotely exploitable bugs... ignoring the 'security' of the
applications that get installed and even side-loaded with full perms.

Hence if you think your phone is insecure, getting out of the Android
world is a good start. (unless you have Nexus devices, as that seems to
be the only semi-maintained thing, or you are making your own custom
loads on it...)

Also, proper OpSec: disable all mediums you are not using. You are not
letting Bluetooth active when you are not using it I hope? Or traveling
with Wifi enabled even though you do not expect Wifi to become
available? Also, you did disable the
automatically-connect-to-any-open-hotspot-willing-to-steal-my-data
setting I hope? :)

> 4) someone has to know how to use it and which login is for what
> account.

That is primarily because of the niche, if it where more common it would
be trickier. This argument is almost the same as writing your passwords
in reverse on a piece of paper or using rot13...

Always remember than an adversary that wants to get specifically to your
data will do exactly that: rubber hose crypto...

> so i would feel much happier knowing its offline 95% of the
> time and has very limited attack vectors.

Offline is a very very good thing.

That is why most bank tokens are offline and why 2FA tokens do not need
connectivity to function (though they need correct time depending on the
algorithm).

This is also why most of these USB tokens (mooltipass included) only try
to expose only a 'keyboard' kind of interface and no way of updating
firmware and other software on the device.

> and to me is 4 factor. and a
> lot lot safer than my old street name and pet
>
> If the same device could be used for both then people could choose how
> secure they want to be? if they want one device just for passwords and
> one for 2fa/u2f then they can set them up that way, or one device for
> everything

The thing is, people who do not know about security properties would
think they are fully secure, and then when that is proven to be false
would complain about it....

> (I personally want one for work and one for play)

You should keep work and home stuff 100% separated.... and hopefully
your company has a proper security measures, recommend them mooltipass!

But definitely also ask for FIDO U2F and similar tools. There are
bunches of 'security' companies that offer the right tools to equip a
whole organization with proper access tools. (RSA tokens are very
ancient by now).

Greets,
Jeroen

Chris Huitema

unread,
Aug 24, 2016, 8:57:11 AM8/24/16
to mooltipass, chris....@gmail.com
Totally agree with everything you have said, but i think you have been watching too much Mr Robot!


On Wednesday, 24 August 2016 19:32:11 UTC+8, Jeroen Massar wrote:
On 2016-08-24 13:10, Chris Huitema wrote:
> the best thing about the Mooltipass is it overcomes the shortfalls
> of *now*, it remembers the few dozen passwords we all currently need
> (and it does really well)
>
> and while i do agree that adding Fido u2f to sites may be easy (well
> over my head to be honest!), many haven't yet and the majority (more
> than 80% of the accounts i have) don't even have 2fa.
>
> I have enabled 2fa on every account i can, and currently use my phone to
> provide 2fa, and it works well but I'm really concerned about all the
> vulnerabilities with such a device that i use for everything, that is
> exposed 24/7 to 3G/4G, BT, NFC, WiFi + whatever other ways it could be
> compromised

And the point of 2FA is that it is irrelevant that a single token gets
compromised. You need both Factors to successfully authenticate.

If your phone gets stolen/hijacked/hacked etc, it does not matter, as
they still need your password. 
 
Also, 2FA tokens are single-use/time dependent, thus re-use is not possible.

the Mooltipass has a Pin, likewise my phone (different pin though)
 
> So yes having the Mooltipass do both password and 2fa may be slightly
> less secure, at the end of the day its still 1) a device someone has to
> have

Like your phone that you carry around, if somebody is close by they will
be able to take it, just as well as they would be able to access it over
the connectivity you allow.

And as the mooltipass is shiny they will take it and then figure out it
needs a PIN which makes it useless. (which FIDO U2F tokens do not have,
but, for those you still need the second password).

totally couldn't resist a Mootipass mini! 
> 2) a card someone has to have,

Do you unplug it and store it separately in a secure place?
yes, on a necklace with my work swipe card 

What if you travel? Put it in two bags that thieves steal together?
(In that situation I keep the card on me, while the reader goes
elsewhere; though often it just stays in a safe ;) )
reader in my laptop bag, card in my necklace 

I know my bank token always has the card inserted... this as when
somebody gets into my house, they also have the option of politely
asking me for the details (read: rubber hose crypto).

> 3) has a pin someone needs to know

The PIN is a great part of the mooltipass.

Though, has it been fully tested against automated testers ala an iPhone
(which has amazing security properties btw).
correct me if I'm wrong, but its part of the card not the mooltipass.. fuses get fused with 3 wrong tries? im sure the nsa has tools to bypass that tho 

Android 'security' is just a farce though...

Check:
https://developer.android.com/about/dashboards/index.html

WOW! is that all they have? i expected much much more :) i bet they know what color undies I'm wearing
wow, Marshmellow has a full 15% of the market already, even after being
a full year on the market. Lets see how low the percentage will be for
Nougat now that has been released recently to select devices.

4.4 KitKat is from 31 October 2013, thus almost as good as 3 years old.
70% of the users are still on that all affected by StageFright and many
many other remotely exploitable bugs... ignoring the 'security' of the
applications that get installed and even side-loaded with full perms.

Hence if you think your phone is insecure, getting out of the Android
world is a good start. (unless you have Nexus devices, as that seems to
be the only semi-maintained thing, or you are making your own custom
loads on it...)

Also, proper OpSec: disable all mediums you are not using. You are not
letting Bluetooth active when you are not using it I hope?
its on always.. for the watch 
Or traveling
with Wifi enabled even though you do not expect Wifi to become
available?
Yep.. even at home its off 
Also, you did disable the
automatically-connect-to-any-open-hotspot-willing-to-steal-my-data
setting I hope? :) 
 
> 4) someone has to know how to use it and which login is for what
> account.

That is primarily because of the niche, if it where more common it would
be trickier. This argument is almost the same as writing your passwords
in reverse on a piece of paper or using rot13...
how did you know my secret :O 

Always remember than an adversary that wants to get specifically to your
data will do exactly that: rubber hose crypto...  

> so i would feel much happier knowing its offline 95% of the
> time and has very limited attack vectors.

Offline is a very very good thing.

That is why most bank tokens are offline and why 2FA tokens do not need
connectivity to function (though they need correct time depending on the
algorithm).

This is also why most of these USB tokens (mooltipass included) only try
to expose only a 'keyboard' kind of interface and no way of updating
firmware and other software on the device.
yes agreed, although i would like BT keyboard option..  for the old kitkat tablet :p

> and to me is 4 factor. and a
> lot lot safer than my old street name and pet
>
> If the same device could be used for both then people could choose how
> secure they want to be? if they want one device just for passwords and
> one for 2fa/u2f then they can set them up that way, or one device for
> everything

The thing is, people who do not know about security properties would
think they are fully secure, and then when that is proven to be false
would complain about it....
 yeah, i was caught out, i was stupid so i took it on the chin. Now i am more cautious, i don't trust anyone or any site i sign up to. I'm a little less concerned with physical security than i am with a site being compromised and my data being stolen. 

> (I personally want one for work and one for play)

You should keep work and home stuff 100% separated.... and hopefully
your company has a proper security measures, recommend them mooltipass!
I have already.. and a couple of clients are looking at them too 

Jeroen Massar

unread,
Aug 24, 2016, 9:18:47 AM8/24/16
to moolt...@googlegroups.com
On 2016-08-24 14:57, Chris Huitema wrote:
> Totally agree with everything you have said, but i think you have been
> watching too much Mr Robot!

Nothing to do with a strange TV series, something to do with $work

Also, no such thing as Amazon Video in Switzerland... could not watch it
even though I want to give them money for it...

Greets,
Jeroen


Nistur

unread,
Aug 24, 2016, 9:32:57 AM8/24/16
to moolt...@googlegroups.com

I definitely agree that the best solution is to have a totally separate token device, so you have true two factor authentication, however while reading this thread this morning, I had an idea...

If the Mooltipass were to support 2FA of some form and could protect each generator with a separate PIN, then having to enter a PIN for them does kind of satisfy the 2FA requirements, as a potential attacker would need the device,  the card and the account PIN for the password, and then also a further PIN for the 2FA.

For those of us who would want it entirely separate, we could then just keep two devices, one for passwords and one for 2FA, but they'd be the same battle tested hardware and software, rather than having to come up with a new design.

Anyway, just my thoughts

Phil



Greets,
 Jeroen


Jeroen Massar

unread,
Aug 24, 2016, 9:42:57 AM8/24/16
to moolt...@googlegroups.com
On 2016-08-24 15:32, 'Nistur' via mooltipass wrote:
> I definitely agree that the best solution is to have a totally separate
> token device, so you have true two factor authentication, however while
> reading this thread this morning, I had an idea...
>
> If the Mooltipass were to support 2FA of some form and could protect
> each generator with a separate PIN, then having to enter a PIN for them
> does kind of satisfy the 2FA requirements, as a potential attacker would
> need the device, the card and the account PIN for the password, and
> then also a further PIN for the 2FA.

Just having a PIN that would be required to unlock the 2FA token every
once in a while (eg card eject/insert) would solve that.

An unlocked mooltipass would be painful though ;)

Same rubber hose technique still works; but just stealing it would not
gain the thief any information they had before.

Greets,
Jeroen

Andrew Kraut

unread,
Aug 24, 2016, 4:57:22 PM8/24/16
to mooltipass
I feel like the paranoia creep is going a bit too far in this discussion. If you look at what 2FA is, you are authenticating with Something you know, and Something you have. Back in the Day(tm), you had something like an RSA token on your keychain. Perhaps now you have a Yubikey with the new U2F standard. Either way, those fulfilled the "Something you Have" requirement and your password fulfilled the "Something you Know" requirement.

By putting your credentials into your Mooltipass, you're replacing the "Something you Know" element with a full 2FA setup. (Have: Smartcard, Know: PIN) While storing both the Have and the Know elements of, say, Google on the same device would generally be a bad idea, you're still wrapping them with 2FA due to the design of the Mooltipass system.

Personally, I would argue that's better than storing both in 1Password, protected with only a password. (Or even storing the password on your phone, and the OTP Pin in Google authenticator on the same device.) Either way, Mooltipass is intended to reduce the friction of a good password management policy: Allow the user to choose unique, highly secure passwords without the burden of memorizing them, without sacrificing a significant (arguably, if any) amount of security. It's ultimately up to the user to choose how they want to secure their credentials. If I am willing to accept an increase in risk in order to gain some ease of use, that's my prerogative. If I'm not, I can buy two mooltipasses and divide 2FA and Passwords between them.

Jess Haas

unread,
Aug 24, 2016, 5:07:39 PM8/24/16
to Andrew Kraut, mooltipass

Implementing 2FA in the mooltipass significantly improves the situation if the computer is compromised or there is a man in the middle attack without requiring any extra effort on the part of the user. 2 separate devices are not necessary for this extra protection.


--

Antonio Cunha Santos

unread,
Aug 24, 2016, 6:35:51 PM8/24/16
to Jess Haas, Andrew Kraut, mooltipass
Good evening,

Well, I would use 2FA in the mooltipass.

About the security concerns, as long as there are 2 pin codes one for the password locker and another for each time the 2FA is to be used, for me it's safe enouth.

If whatever information one is trying to protect is worth the time and resources, it will be accessed, no matter what, one uses to protect it! It's all about how much is it worth!

About two factor auth, all my sms tokens are sent to my "dumb phone", and old nokia C2-01, as I dont trust smartphones for that task, so I use a disposable card on a "dumb phone. My smartphone only connects to trusted wifi networks, and even though, I keep using VPN clients to access whatever I need on the internet while using wifi. Maybe a bit paranoid, but rather be safe than sorry.

The only security vector, that I believe cant be patched is "stupidity", cause lots of ppl continue to use passwords that can be guessed! I mean, last time I did a fisical security audit it was so easy to guess lots of passwords by just having coffee with the workers, and look at their desks. Some used stuff like pet's name + birthdate, kids names and birth dates, spouse or girlfriend, soccer team, and so on... So that cant be fully patched! So, as long as whatever the password is protecting is worth it, someone will use the resources to access the information!

I've read about the home invasion, in one of the mails of the topic, and it kind of made me think: Wouldn't everyone tell the password and whatever asked, to an armed intruder, under coercion ?

I mean, for this there is just no defense, other than some "nasty tricks", or having totaly "satisfying the question, but the answer per si is useless". Also this is dangerous waters, as criminals dont really have limits. This could hold under interrogation, but not under life threatening situation.

best regards,

Santos



António Pedro Oliveira Cunha Santos

"Patience is the companion of wisdom." Aurelius Augustinus Hipponesis"

Chris Huitema

unread,
Sep 1, 2016, 9:21:27 AM9/1/16
to mooltipass
Ok, so I've gone through the source code and have a bit of an idea how this awesome little black box works, now I'm hashing out a few ideas and would like some input 

The first problem i see is getting the current time and date onto the Mooltipass, once its set it can stay up to date while the device is powered reasonably accurately for short periods - within spec for 2fa anyway.
 so the app should be able to send the time to the MPM and shouldn't be a problem when connected to a known system with the app installed. 
    -> send Unix time and the offset/timezone of the computer, and store it somewhere, and keep it updated from a timer. (there is current date in the firmware already, but might as well just store unix time +offset, although its a 32bit instead of the 16bit currently used)
 for offline use and when the app isnt installed - 
    -> im thinking something similar to the way the pin is entered, timezone +XX, next screen DD,MM, YYYY then next screen HH MM SS.  the values can be pre-populated with the last known values before the device was powered down
So can anyone suggest a better way to do this? 

next is entering the secret, normally this is base32 encoded. and shouldn't be to bad to enter with the current way of entering/modifying creds. maybe change the char set to A-Z 2-7 so its quicker and reduces the chances of wrong values to be entered (eg 8 instead of B)
but im guessing there will be a range of other settings too, maybe start with default values and only change if needed. similar to time and date above i guess. 
 -> now im gonna have a guess that most of the time when setting up an account with 2fa you will be on a trusted computer with the app installed anyway so it would be awesome if there was a way to screen capture the "barcode" from the mooltipass app and send it to the device.. thats well over my head!

Now onto secret storage... im still a little confused and need to read the node management section a few dozen more times! 
with the suggestions about needing to enter a pin to get them i was thinking why not set up a different smartcard, with different pin and aes key if thats the way the user wants to go. otherwise have it all in the one user/card 
then there is secret encryption.. just use the same as password? its already implemented.

can anyone see anything I'm missing? i know its going to be a massive task for someone like me.. but i want to give it a go and lean along the way. 


   

mathieu...@gmail.com

unread,
Sep 1, 2016, 9:41:03 AM9/1/16
to Chris Huitema, mooltipass
Hello Chris,

Could you remind me why exact time is required for 2FA? IIRC HOTP is also a solution.

Reading your write-up and competencies, I'd strongly recommend making a complete google docs documents explaining how you'd implement 2FA on the device, and also which 2FA you'd use.

As for the node management part, I could definitely help you.

Cheers,
Mathieu


--

Andrew Kraut

unread,
Sep 1, 2016, 3:54:35 PM9/1/16
to mathieu...@gmail.com, Chris Huitema, mooltipass
Supporting TOTP would definitely improve compatibility with various sites. Most of the ones I have 2FA tokens from, are issuing TOTP.

To unsubscribe from this group and stop receiving emails from it, send an email to mooltipass+...@googlegroups.com.

To post to this group, send email to moolt...@googlegroups.com.
Visit this group at https://groups.google.com/group/mooltipass.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "mooltipass" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mooltipass/RwoY4VN04Bk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mooltipass+...@googlegroups.com.

Chris Huitema

unread,
Sep 1, 2016, 11:44:29 PM9/1/16
to mooltipass, chris....@gmail.com
As andrew mentions most 2FA tokens use TOTP, the difference i can see is that HOTP uses a counter, each use just increments the counter to get a new code. the TOTP builds on that and basically uses (current time - epoch) / period to generate the counter. generally epoch is 0 and period is 30sec. so right now its (1472811600-0)/30 = 49093720 thats the number used for the counter. so exact time

from what i can gather from using several of these tokens daily on offline systems (where clocks vary by 30-90seconds) they generally accept 2 or 3 codes at any given time (current one and previous one), occasionally ive had to adjust the clock on my phone to match the computer time for it to work correctly.

Hence the need for time. within a few seconds is OK and the timers should be able to maintain this easily while the device is powered. 

Do you have an example of what you would like in the google doc? im more than happy to whip something up. 
I was planning on HOTP and TOTP with the standard settings like algorithm, epoch and period (if totp), counter (if hotp) and digits.  

Also on a totally different subject, i was looking at the new cred management on board (and how to use it for the above) how is it scrolling through 96 characters when entering creds? 

I was thinking would it be possible to have the long click bring up a menu, something like this
A-Z
a-z
0-9
! ( @ 
<-
XX
OK
it could just set/return the offset for character entry, ie A-Z ctr=0, a-z ctr=26, 0-9 ctr=52 etc. and then for the 3 special ones it just selects them. also how much space is left in the flash for more LUT? im wondering if this code could be modded slightly to allow custom char sets? maybe use shared ones with charsets for password generation?

Anyways.. baby duties gtg




To unsubscribe from this group and stop receiving emails from it, send an email to mooltipass+...@googlegroups.com.

Pierre

unread,
Sep 2, 2016, 8:53:31 AM9/2/16
to Chris Huitema, mooltipass
Hello Chris,

I developed the on-board credential management feature.

On 02 Sep 2016, at 05:44, Chris Huitema <chris....@gmail.com> wrote:
> Also on a totally different subject, i was looking at the new cred management on board (and how to use it for the above) how is it scrolling through 96 characters when entering creds?

There are 95 available characters in the charset of the font (printable on the OLED screen), so it identifies each character with its offset to ‘A’. 3 “virtual” offsets are appended to the charset to handle special codes for backspace, cancel and confirm. So the range of possible values spans 0 to 97.

There are currently only two modes of entry: 8-bit unsigned integer (easily enhanced to 16-bit integers if needed) or text-entry. The latter fills a provided buffer with the user-submitted string and handles everything, there’s no split to handle selection on a per-character basis: the same function currently does everything.

> I was thinking would it be possible to have the long click bring up a menu, something like this
> A-Z
> a-z
> 0-9
> ! ( @
> <-
> XX
> OK
> it could just set/return the offset for character entry, ie A-Z ctr=0, a-z ctr=26, 0-9 ctr=52 etc. and then for the 3 special ones it just selects them.

Why not rely on integer entry then? We could easily add a “step” value, and I’ll probably add support for fast scrolling with click+scroll.

> also how much space is left in the flash for more LUT? im wondering if this code could be modded slightly to allow custom char sets? maybe use shared ones with charsets for password generation?

The charset string used for text entry is currently stored seperately from the LUTs within the resource bundle. See mooltipass/bitmaps/mini/fw_strings.txt. Custom strings could be stored there (requires flashing) or you’d need to add support for such kind of storage (possibly a data storage node, giving you 128 bytes). Again, a few lines of code, you can see how my pull request #216 implements credential renewal.

The on-board credential management feature adds 2.2KB of code, which exceeds currently available space. It requires stripping the current firmware from various features such as favorites, stack debugging, data storage and accelerometer support among the major ones.
The text-entry routine compiles to more than 1KB alone, which is more than currently available.

However, if you plan on stripping support for login selection/storage altogether, you will have plenty of space available.

Cheers,

Pierre Capillon

Chris Huitema

unread,
Sep 2, 2016, 11:41:41 PM9/2/16
to mooltipass, chris....@gmail.com
I found the PR the other day and thats what alerted me to the input feature..

Do you have a video of the text entry in operation? im trying to picture how it looks on the screen
Reply all
Reply to author
Forward
0 new messages