Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OnlyKey: Open-Source Alternative to YubiKey

onlykey.io

Post reply on HN
Print view View original

101–110 of 215 posts

Re: OnlyKey: Open-Source Alternative to YubiKey

#101

Post by fierarul »

91iejrj20310 wrote: post #78
fierarul wrote: post #67

Earlier quoted context omitted.

The way two factor auth works is that you register your hardware key and you also get 10 one-time-usage recovery codes which you can use instead. So, if you lose your YubiKey, you can still login 10 times using a recovery code. Presumably during those 10 times you either disable 2FA or register a new YubiKey.

I guess those recovery codes are the new security questions - yes theoretically they are there to recover your account, but in practice, you won't have them at hand unless you stored them in your password manager.

The whole idea of having a hardware token is to separate what's at hand. Having the recovery codes in the password manager seems like a bad idea. Google recommends printing them.

Re: OnlyKey: Open-Source Alternative to YubiKey

#102

Post by PeterisP »

imtringued wrote: post #62

I honestly don't understand how a YubiKey is supposed to help me secure my accounts if I get locked out of my accounts when I lose it. I an trivially copy a keepass database anywhere and have dozens of backups. If I want to do the same with a YubiKey I first have to buy multiple YubiKeys and then I have to register each one on each site. This means they cannot be used as a primary authentication method because they a…

Well, if you have multiple yubikeys on each site, then it can be used as a primary authentication method - because if you lose yubikey A, then the emergency fallback is yubikey B which you can use to revoke the access of yubikey A and add yubikey C instead.

Or, you have a set of one-time codes for recovery. I have accounts with a lot of sites, and all the sites that support proper U2F did have one-time recovery code option, because that's the fallback system that makes a lot of sense together with hardware tokens. Yes, the sites that support only things like phone-based OTP usually don't bother, since their risk model anyway puts all the trust in the phone so they usually just have a phone-based fallback, e.g. SMS with all the security risks related to that.

Or, you initialize two yubikeys so that they're identical; so you use your primary key and store the backup key somewhere safely, this doesn't require you to register multiple keys at each site, so it's a bit more convenient but it makes revoking a lost key a much bigger pain.

Re: OnlyKey: Open-Source Alternative to YubiKey

#103

Post by blattimwind »

nemonemo wrote: post #42
tptacek wrote: post #36

Earlier quoted context omitted.

Passing dieharder doesn't mean anything at all with respect to cryptographic security. It's trivial to define a random bit generator that passes randomness tests and has no real security.

I would like to learn more about practical cryptographic issues, and I need some help: what are the tests that can prove or disprove stronger guarantees for cryptographic security of a PRG than diehard? A wikipedia page doesn't give me much info about which one provides stronger guarantee and in which criteria: https://en.wikipedia.org/wiki/Randomness_tests Also, which level of security of a PRG is sufficient for key…

> what are the tests that can prove or disprove stronger guarantees for cryptographic security of a PRG than diehard?

None. The difference between a good CSPRNG and a broken one might not even be in the construction at all, but in who knows the seed. For example, a keystream generated using Chacha20 or AES-CTR makes for a good CSPRNG... except if the attacker knows the key.

Re: OnlyKey: Open-Source Alternative to YubiKey

#104

Post by rodgolpe »

Tomdarkness wrote: post #91

One thing I immediately noticed is that apparently it supports exporting full backups of the device? Surely this is a terrible idea? I'm far from a security expert but I'd have thought you'd want to make it so that it is extremely difficult to extract key material from a security key, not offer it as a feature?

The backups are automatically encrypted with a private key you save onto the device (obviously the key is not part of the backup). To restore a backup onto the same device or a new OnlyKey, you first have to load the same private key that encrypted your backup.

Re: OnlyKey: Open-Source Alternative to YubiKey

#105

Post by blattimwind »

RL_Quine wrote: post #64
marcan_42 wrote: post #53

Earlier quoted context omitted.

Flash readout protection on most microcontrollers is a joke. They are almost always vulnerable to attacks ranging from power/clock glitching to asking nicely with the right combination of flash management commands (I'm looking at you, some PICs from the PIC18 series with blockwise erasable Flash including protection bits). I've seen some things disable their read protection by accident because the power supply wasn't…

I've signed a ot of these NDAs. Dirty little secret, most of them are DUAL_ED_DRBG which is backdoored. None of them have any meaningful protection, and usually they have sidehcannels the size of mountains. There's none of the secure element chips I would consider to be stronger than cryptography in software. They're the same as passing certifications, good to corporate management but a joke to anybody who knows what…

Can you comment, perhaps vaguely, on the Infineon SLE 78 series?

Re: OnlyKey: Open-Source Alternative to YubiKey

#106

Post by tptacek »

RL_Quine wrote: post #64
marcan_42 wrote: post #53

Earlier quoted context omitted.

Flash readout protection on most microcontrollers is a joke. They are almost always vulnerable to attacks ranging from power/clock glitching to asking nicely with the right combination of flash management commands (I'm looking at you, some PICs from the PIC18 series with blockwise erasable Flash including protection bits). I've seen some things disable their read protection by accident because the power supply wasn't…

I've signed a ot of these NDAs. Dirty little secret, most of them are DUAL_ED_DRBG which is backdoored. None of them have any meaningful protection, and usually they have sidehcannels the size of mountains. There's none of the secure element chips I would consider to be stronger than cryptography in software. They're the same as passing certifications, good to corporate management but a joke to anybody who knows what…

Can you talk us through a scenario where you'd exploit Dual_EC to break encrypted flash storage?

Re: OnlyKey: Open-Source Alternative to YubiKey

#107

Post by annolir »

ykpass (https://github.com/noliran/ykpass) takes another approach at this. It generates unique strong passwords for every website, which are fully restorable without needing constant backups, thus providing a solution for non-U2F websites, which is - honestly - most of the internet at the moment

Re: OnlyKey: Open-Source Alternative to YubiKey

#108

Post by LaGrange »

fierarul wrote: post #101
91iejrj20310 wrote: post #78

Earlier quoted context omitted.

I guess those recovery codes are the new security questions - yes theoretically they are there to recover your account, but in practice, you won't have them at hand unless you stored them in your password manager.

The whole idea of having a hardware token is to separate what's at hand. Having the recovery codes in the password manager seems like a bad idea. Google recommends printing them.

...oh yes, having your passwords printed out is such a great improvement. Considering how likely the "hacker" is to be a person sharing your household, you might as well put them on a post-it note and stick them to the screen.

Recovery codes go straight into the password manager, right next to my mother's maiden name, ASuTeil7quoongak2aeniVar.

Re: OnlyKey: Open-Source Alternative to YubiKey

#109

Post by Stratoscope »

marcan_42 wrote: post #57
Tharre wrote: post #27

Earlier quoted context omitted.

The "security" of this device is a joke, just look at how randomness is derived: unsigned int analog1 = analogRead(ANALOGPIN1); RNG.stir((uint8_t *)analog1, sizeof(analog1), sizeof(analog1)*2); unsigned int analog2 = analogRead(ANALOGPIN2); RNG.stir((uint8_t *)analog2, sizeof(analog2), sizeof(analog2)*2); (See [0] for a comprehensive summary of why this is a terrible thing to do) And yeah, analogRead() is a function…

It seems this is literally written in the horrible Arduino "everything in one huge file" style: https://github.com/trustcrypto/OnlyKey-Firmware/blob/master/... The funny thing is they have a "Source code reviewed by Codacy" badge on the readme claiming the code is grade A... but if you actually click through, of course Codacy didn't pick up the .ino file at all, so in fact nothing of substance is being reviewed. That…

The 7000 lines don't bother me as much as the complete lack of refactoring, heavy use of magic numbers repeated throughout, and logical expressions that duplicate logic over and over again.

Some examples...

Compare these two blocks of assignments and memcpy calls:

https://github.com/trustcrypto/libraries/blob/5bd1f8eb15eb04...

https://github.com/trustcrypto/libraries/blob/5bd1f8eb15eb04...

Yes, they are as identical as they appear. The only differences (other than a couple of lines commented out in one) are the use of 'data' in the first and 'large_resp_buffer+offset' in the second, along with some arbitrary whitespace differences. (The first uses spaces around the + operators, the second does not.) And all the hard coded numbers! What do they mean?

Or this block of code that appears to be a limited version of a decimal number formatter:

https://github.com/trustcrypto/libraries/blob/5bd1f8eb15eb04...

Or this code that keeps checking the same flags over and over again instead of combining the tests:

https://github.com/trustcrypto/libraries/blob/5bd1f8eb15eb04...

(Scroll horizontally to see all the repeated tests!)

Or this code with the same logic repeated 24 times:

https://github.com/trustcrypto/libraries/blob/5bd1f8eb15eb04...

The next function after that one also has 24 copies of duplicate logic.

Well, the logic isn't entirely duplicated. The individual cases call functions like onlykey_eeget_urllen1, onlykey_eeget_urllen2, ... onlykey_eeget_urllen24, and onlykey_eeset_urllen1, onlykey_eeset_urllen2, ... onlykey_eeset_urllen24. Here are those functions:

https://github.com/trustcrypto/libraries/blob/527113dfeeb20e...

Yes, they are all identical except for the different constants each one uses:

https://github.com/trustcrypto/libraries/blob/527113dfeeb20e...

This pattern of "24 copies of the same logic with different constants" occurs all through the code. Look through okeeprom.h/cpp for several other examples.

None of this inspires confidence that the code can be trusted.

Re: OnlyKey: Open-Source Alternative to YubiKey

#110

Post by unwind »

Tharre wrote: post #27
dehugewe1209 wrote: post #15

Security keys are the heart of security and we desperately need open-source solutions on this. Kudos for doing it. Now, I must point out a few things: 1. Please don't call your solution "Open-source", when you do not have not even the schematics uploaded to github. 2. (this item is an open problem without a solution yet) how do I make sure the source code and the (still missing) hardware information actually correspo…

The "security" of this device is a joke, just look at how randomness is derived: unsigned int analog1 = analogRead(ANALOGPIN1); RNG.stir((uint8_t *)analog1, sizeof(analog1), sizeof(analog1)*2); unsigned int analog2 = analogRead(ANALOGPIN2); RNG.stir((uint8_t *)analog2, sizeof(analog2), sizeof(analog2)*2); (See [0] for a comprehensive summary of why this is a terrible thing to do) And yeah, analogRead() is a function…

Uh that is treating the value from the A/D conversion as an address, and reading that location for data to stir in.

Unless HN markup ate the &s that are missing.

That is very bad code indeed.

Post reply on HN