Jump to content

Native Yubikey Support


CentOS

Recommended Posts

I would sure like this. I believe the reason the Blesta team does not want to do it is because it is run by a third party.

 

However, its not like someone can "hack" that server at yubico and then just get in, they still need a user/pass.

Link to comment
Share on other sites

Does Blesta have native Yubikey support like WHMCs?

 

WHMCS does not have native Yubikey support but outsources the validation to the Yubikey webservice.

Meaning your secret seed value has to be stored by Yubico in their central database, rather than stored locally in your WHMCS installation.

Wouldn't recommend that, given what happenend to the central database of another OTP vendor (Second Defense Contractor L-3 ‘Actively Targeted’ With RSA SecurID Hacks)

 

 

Blesta does support storing seeds locally.

It only supports time based TOTP and not event based OTP though.

Meaning you have to install a helper program (that is only available for Windows) for the Yubikey to work, as it doesn't have a clock.

Not perfect either.

Link to comment
Share on other sites

WHMCS does not have native Yubikey support but outsources the validation to the Yubikey webservice.

Meaning your secret seed value has to be stored by Yubico in their central database, rather than stored locally in your WHMCS installation.

Wouldn't recommend that, given what happenend to the central database of another OTP vendor (Second Defense Contractor L-3 ‘Actively Targeted’ With RSA SecurID Hacks)

 

 

Blesta does support storing seeds locally.

It only supports time based TOTP and not event based OTP though.

Meaning you have to install a helper program (that is only available for Windows) for the Yubikey to work, as it doesn't have a clock.

Not perfect either.

 

TOTP works on Android (I have it on my phone)

Link to comment
Share on other sites

TOTP works on Android (I have it on my phone)

 

Yeah, but most users have a nasty habit of entering passwords on their phone as well.

So if your phone ever becomes compromised, the attacker has both access to your password and the second factor.

People regard their phone as more secure than their computer, yet have more apps from unknown sources on them, than they would ever install on their regular computer.

 

Real OTP tokens are much more secure.

Link to comment
Share on other sites

 
It's really not difficult in theory to implement native support into Blesta, its just the fact of modifying the user settings page to add another type of 2 factor authentication and inserting a column into the database to hold the ID of the Yubikey.
 
Before John screams foul on something, if the cron relies on connecting to Stripe, PayPal, etc... (let alone license activation check) that server has to be online. So having it connect to Yubico's servers is not an issue. Besides, the connection to Yubico is always secure so I don't get what the issue is.

I honestly would rank authentication at the same level of security handling as the merchant gateways since they are both transmitting crucial data and receiving small but important responses back.
 
(I'll be honest here and say I use Authy for my authentication since they have OTP sync and there is also a client for just about every platform that a browser can run an extension on and also that my Yubikey is also an older generation so it does not support OTP.)
Link to comment
Share on other sites

We may add third party two factor services in the future, but we went through the effort to create our own TOTP and MOTP libraries based on the open standards because a self contained system is by nature more secure.. plus, it's free.

 

Perhaps a more modular system, by which third party developers can create different OTP options, and drop them into Blesta would be ideal. There will undoubtedly be more and more options available over time.

Link to comment
Share on other sites

 

 
It's really not difficult in theory to implement native support into Blesta, its just the fact of modifying the user settings page to add another type of 2 factor authentication and inserting a column into the database to hold the ID of the Yubikey.
 
Before John screams foul on something, if the cron relies on connecting to Stripe, PayPal, etc... (let alone license activation check) that server has to be online. So having it connect to Yubico's servers is not an issue. Besides, the connection to Yubico is always secure so I don't get what the issue is.

 

Wouldn't call outsourcing the validation to a webservice native.

Doing the validation locally is native: https://code.google.com/p/yubiclass/source/browse/#svn%2Ftrunk

 

Main difference is that instead of storing a Yubikey ID in the database, you need to store the AES key you programmed into the Yubikey, and the counter that was last used during login (must always be higher on subsequent logins).

2 database columns instead of 1.

 

 

 

Besides, the connection to Yubico is always secure so I don't get what the issue is.

 

I wouldn't blindly trust the security of the servers and integrity of the personnel of any third party organization, if it can be avoided.

Same reason I disagree with Blesta currently sharing the secret seed key with Google (it is using Google charts to generate a QR code of it)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...