Yubikey Authentication Support

[CraigA]

Something to look into, integrating yubikey support into the admin panel authentication.

 

http://www.yubico.com/about/intro/

 

I use yubikey's for all the servers I admin, would be nice to be able to use it for Blesta as well.

 

Thanks!

CraigA

[Michael]

I believe Blesta is having it, not sure when though, because they have their own.

 

 

They got it on the 7th May, which was just before the Beta testing went live which was the 15th May.

[Paul]

It is supported now. See http://docs.blesta.com/display/user/Logging+In scroll down for the section on Yubikey. Make sure you have another full rights admin account you can login and remove the TOTP settings in case things go sideways, but I did test this with our Yubikey and it was working just fine.

[Michael]

It is supported now. See http://docs.blesta.com/display/user/Logging+In scroll down for the section on Yubikey. Make sure you have another full rights admin account you can login and remove the TOTP settings in case things go sideways, but I did test this with our Yubikey and it was working just fine.

Oh haha I thought you'd have a option in the dropdown box saying Yubikey .

[Paul]

Oh haha I thought you'd have a option in the dropdown box saying Yubikey .

 

That's not really necessary, though it might make things clearer for those wondering if it's supported.

[Michael]

That's not really necessary, though it might make things clearer for those wondering if it's supported.

I agree maybe a link under the form saying Looking for Yubikey click here. with the link to the docs .

[CraigA]

Yaaay! Thanks guys!

[medfordite]

Not to bring up an old topic but...

 

Has Blesta considered an API Based authentication module instead of the current method you are using with the Yubikey?

 

For example, WordPress (And many other scripts) has a Yubikey module which does the API Call back to the Yubico server (Or one the Yubikey Owner sets up if they choose on their own hardware for this purpose), then if things are all warm and fuzzy and passes the authentication, it lets you in.  This eliminates the need for TOTP.

 

On a side note, I was shocked to discover that Google Authenticator's TOTP is really not as random as I thought.  I have both an Android Tablet and Phone running the authenticator.  Both are set for the same sites and if I launch them at different intervals 30 seconds apart (Or after the counter changes to a new number on a device), The code is the same as the other device before it changed the code.  For Example:

 

Phone displays:  885741

Tablet Displays:  751291

 

After The Interval Change:

 

Phone Displays: 958231

Tablet Displays:  885741

 

Unless I am not understanding TOTP correctly, this would seem to be a 1 Minute Window for Verification as opposed to the 30 second window. (30 seconds on each device)

 

To me, this is not nearly as secure as Yubikey.  With the Yubikey, once your password is used - it is tossed into the abyss to never been used again.  Having an API Based plugin instead of what you are using now, would make IMHO an easier configuration for plug and play and also allow more universal integration.

[Paul]

As a general rule, we try to avoid becoming dependent upon a third party for core functionality, especially when it comes to security.. there's just so much more that can go wrong. Whether it be a man in the middle attack, or a downed service that prevents you from logging in.

 

Our implementation allows for a 3 minute window I believe, and I'm pretty sure that's standard. Your token generator may change more or less frequently, but it's irrelevant. There's nothing random about a TOTP token, it's all based on the time.

 

I think it's a lot more secure, and reliable to use the TOTP method as we have implemented it. It relies on no third party service, there are no fees, and no API calls that could be vulnerable to attack or outage. That's not to say we will never integrate with a 3rd party two factor service, but we would certainly never use it ourselves.

[Max]

Problem with TOTP is that it is not natively supported by the Yubikey, and only works for Windows users that have their helper program installed.

Any specific reason not to support Yubi's event based algorithm instead?

Can be computed locally as well, without depending on external servers.

(although it requires a little bit of extra work, as you need to store the new event counter in the database after each login).

[Cody]

On a side note, I was shocked to discover that Google Authenticator's TOTP is really not as random as I thought.  I have both an Android Tablet and Phone running the authenticator.  Both are set for the same sites and if I launch them at different intervals 30 seconds apart (Or after the counter changes to a new number on a device), The code is the same as the other device before it changed the code.  For Example:

 

Phone displays:  885741

Tablet Displays:  751291

 

After The Interval Change:

 

Phone Displays: 958231

Tablet Displays:  885741

 

Unless I am not understanding TOTP correctly, this would seem to be a 1 Minute Window for Verification as opposed to the 30 second window. (30 seconds on each device)

That's completely normal. It just means the time on your phone is slightly ahead of the time on your tablet. TOTP tokens are generated based on a given point in time and a pseudo-random key, the result of which is completely predictable if the key is known.

 

To me, this is not nearly as secure as Yubikey.  With the Yubikey, once your password is used - it is tossed into the abyss to never been used again.  Having an API Based plugin instead of what you are using now, would make IMHO an easier configuration for plug and play and also allow more universal integration.

That's not true. Yubkikey codes may be resused as well (there are only so many possible combinations). The way TOTP is implemented is you may only use a token once within a large block of time. This completely prevents man-in-the-middle attacks through token reuse.

 

Yubikey is a pretty neat device, but I would caution against falling for the sales pitch that it's in any way better than a tried-and-true proven standard for multi-factor authentication such as TOTP. If anything it is less secure as the code used to generate the tokens is proprietary.

 

When it comes to security, the general rule of thumb is if you can not verify the trustworthiness of the algorithm don't trust it.

[Max]

 If anything it is less secure as the code used to generate the tokens is proprietary.

 

When it comes to security, the general rule of thumb is if you can not verify the trustworthiness of the algorithm don't trust it.

 

Not following you. The algorithm to calculate the tokens is publicly available in the technical manual on their website...

 

The only point I do agree with you on is to not use their API, and to program your own seeds in the Yubikey and verify locally.

PHP code for local verification is readily available. 

We use the following LGPL'd code in our own software: https://code.google.com/p/yubiclass/source/browse/#svn%2Ftrunk

(With the difference that we made a small modification to loose the dependency on AES128.php and let it us phpseclib instead

Replaced:

 

require('AES128.php');

$aes=new AES128();

$key=$aes->makeKey(pack('H*',$secret_aes_key));

[...]

$this->yk["token_decoded_bin"]=$aes->blockDecrypt($this->yk["token_bin"], $key);

 

with:

 

require_once( dirname(__FILE__).'/phpseclib/Crypt/AES.php' );

$aes = new Crypt_AES(CRYPT_AES_MODE_ECB);

$aes->disablePadding();

$aes->setKey(pack('H*',$secret_aes_key));

[...]

$this->yk["token_decoded_bin"]=$aes->decrypt($this->yk["token_bin"]);

)

[medfordite]

This is an interesting read - for a company that sells these, they actually admit to a flaw in their design - or at least the exposure to it publicly.

 

http://www.yubico.com/wp-content/uploads/2012/10/Security-Evaluation-v2.0.1.pdf

 

On Page 12 of their documentation found here, they say that the code generated cannot be reused (http://www.yubico.com/wp-content/uploads/2013/07/YubiKey-Manual-v3_1.pdf):

 

 

 

2.3.2

Prevention of replay

The Yubikey OTP algorithm yields a 32 character dynamic string that by design is guaranteed to be unique. The OTP contains linear counters that allow the instance verifying it to determine in which particular order a set of OTPs

have been generated. The security of the Yubikey assumes that the verifying party keeps track of the last sequence number received from a particular device. If an OTP is received where the sequence number is less than or equal to the last number received

, this should be rejected as a replay of an earlier generated OTP

 

Now, I am not nieve enough to think that the code cannot be tossed out forever in spite of what I said, but in the lifetime given the fact that the total number of calculations and generations required to re-generate the same code would probably outlive the device cycle. 

 

You can test the Yubikey login acceptance with the same code over a period of several days or weeks or months by copying it into notepad or whatever you want to store it in, and paste it, you will not be able to authenticate it as it has already been used.    There are known Yuibkey emulators online for download that you can use to  pretend to be one and probably authenticate, but this is only limited to knowing the first 12 digits of a target's key.  Yubikey is aware of this and have implemented hardware and software countermeasures against this to further authenticate the key against their servers.  (Or yours if you want to host one for yourself). 

 

What I was trying to get at with the Google Authenticator was my surprise that on two devices synced to Google, but a second or two apart, the code will "move" from one device to the other.  So, this negates the unique ability for the codes to be used one time. 

[Cody]

Not following you. The algorithm to calculate the tokens is publicly available in the technical manual on their website...

 

Interesting. I found the Security Evaluation to be a good read. I wasn't aware that the token algorithm was published. Though I have some concerns with the use of AES-128, and most especially with ECB mode. Not to mention that the device key is only 6 bytes, and the remaining 10 bytes are quite easy to derive. So there is not much entropy in the non-encrypted token itself, though once encrypted it does appear to be sufficient for its purpose. The only question I have is how is the AES key computed? Hopefully it's not derived from the device key.

[Cody]

You can test the Yubikey login acceptance with the same code over a period of several days or weeks or months by copying it into notepad or whatever you want to store it in, and paste it, you will not be able to authenticate it as it has already been used.

 

 

Only if the server is properly maintaining the counter. TOTP works the same way to prevent code reuse.

[Max]

Interesting. I found the Security Evaluation to be a good read. I wasn't aware that the token algorithm was published. Though I have some concerns with the use of AES-128, and most especially with ECB mode. Not to mention that the device key is only 6 bytes, and the remaining 10 bytes are quite easy to derive. So there is not much entropy in the non-encrypted token itself, though once encrypted it does appear to be sufficient for its purpose. The only question I have is how is the AES key computed? Hopefully it's not derived from the device key.

 

Not sure if ECB block mode matters when only a single block of data is encrypted.

AES key is a 128-bit shared secret that you program in the Yubikey and stick in your own database if you are doing local verifications.

For illustrative purposes, see our instructions for programming a Yubikey and entering the key in our software that does local verification: http://www.noc-ps.com/index.php/documentation/yubikey/

As you see both the (optional) private id and AES key are entered separately and not derived from anything.

 

 

Note that TOTP also carries extra security risks because in practice user programmable hardware tokens are not available for purchase in small quantities (yes, we searched).

Most use a key that is preprogrammed by the factory and there is reason to believe most vendors keep copies.

There was a scandal when RSA's SecurID token database was hacked, and used to compromise a defense contractor.

And gooze.eu stopped selling Feitian's devices because they think they also keep copies.

 

And do not like the idea using a smartphone as a security device either, when it is known that Google employees (and who knows else) can push arbitrary software to your phone.

http://jon.oberheide.org/blog/2010/06/25/remote-kill-and-install-on-google-android/

 

So think Yubi is the most secure option.

[Cody]

Not sure if ECB block mode matters when only a single block of data is encrypted.

It does, somewhat, as the lack of an initialization vector means that two matching plain-texts will always result in the same cipher text, though I am certain this is by design, and as I've stated is sufficient for its purpose (as the likelihood of matching plain-texts is quite low).

 

AES key is a 128-bit shared secret that you program in the Yubikey and stick in your own database if you are doing local verifications.

For illustrative purposes, see our instructions for programming a Yubikey and entering the key in our software that does local verification: http://www.noc-ps.com/index.php/documentation/yubikey/

As you see both the (optional) private id and AES key are entered separately and not derived from anything.

I still don't see how the AES key is generated. Where does the entropy come from to generate the AES key? It really doesn't matter much as you've stated the keys can be reset. So I assume that means I could set it to anything I desired.

 

Note that TOTP also carries extra security risks because in practice user programmable hardware tokens are not available for purchase in small quantities (yes, we searched).

Most use a key that is preprogrammed by the factory and there is reason to believe most vendors keep copies.

There was a scandal when RSA's SecurID token database was hacked, and used to compromise a defense contractor.

And gooze.eu stopped selling Feitian's devices because they think they also keep copies.

I disagree simply because just about any device can be used as a TOTP token generator, so the key need not be hardcoded to the device (any such device is simply a poor design). In fact, the Yubikey itself (but not by itself) can be used as a TOTP token generator.

 

And do not like the idea using a smartphone as a security device either, when it is known that Google employees (and who knows else) can push arbitrary software to your phone.

http://jon.oberheide.org/blog/2010/06/25/remote-kill-and-install-on-google-android/

 

That's true, but only if your device has a network connection (of some sorts), which isn't a requirement of TOTP.

I think Yubikey is neat. Is it the most secure option? Well, that's up to the user and the cryptanalysts to decide.

[Max]

>It does, somewhat, as the lack of an initialization vector means that two matching plain-texts will always result in the same cipher text, though I am certain this is by design, and as I've stated is sufficient for its purpose (as the likelihood of 

>matching plain-texts is quite low).

 

Given that there is a counter in the plain-text that gets incremented each time, you never have matching plain texts.

Note that the entire 128-bit (AES' block size) of plain-text must match exactly for that to apply

Just having some static bits at the beginning does not matter, as it is not a stream cipher.

 

 

>I disagree simply because just about any device can be used as a TOTP token generator, so the key need not be hardcoded to the device (any such device is simply a poor design).

 

In theory yes.

In practice I am still looking for a single vendor that sells standalone TOTP hardware tokens at reasonable conditions (must fit on a key chain, be programmable, cost under $ 100 each, and sell in low quantities, not by the thousands)

 

 

>I still don't see how the AES key is generated. Where does the entropy come from to generate the AES key? It really doesn't matter much as you've stated the keys can be reset. So I assume that means I could set it to

>anything I desired.

 

Yeah, you need to set your own key anyway if you wish to verify locally.

They do not supply you with the preprogrammed one, that is stored by them and can only be used by their API.

 

Don't know where Rob the robot gets it entropy from. :-)

http://vimeo.com/27107146#