techhelper1

SSH keys have nothing to do with email or website authentication. That's only for *NIX nodes/VPS's/etc...

The PHP API is written in a simple way to implement (https://github.com/Yubico/php-yubico). All it needs is a couple of fields added to the admin/user settings, a couple of columns added in the database and then include the API files itself. It's not rocket science to implement so I still don't see what the problem is.

Uhh... the same principle can apply to your phone or tablet if you walk away and I pick it up immediately after, most times the device will not require another unlock since its within the frequent timeframe. From what I remember Google Authenticator has no pin to protect it's TOTP's, Authy does but no one I know uses it or even knows about it. What you don't seem to understand now is that the Yubikey itself is useless since it's the second factor of authentication just like TOTP. You still need the originating password to get the second stage. With the TOTP configuration, the Yubikey just holds the key that the TOTP will generate off of, the helper app does the actual math and takes the system time to generate the resulting number.

Like I've said before, Authy (and probably others) can sync TOTP instances across devices (including computers) and not very many people set locks/passcodes on them to prevent access into it. In fact, I can make a 8Mhz 8-bit processor do TOTP, it's not rocket science. Bottom line, the Yubikey OTP is something that's physically needed and you can't get around it.

Oh... so someone isn't going to steal/break/ruin your smartphone or tablet? That's a lot easier to steal versus something that's on a keychain that's on me or within eyesight. The difference is what technology is being used and how efficient it can be used on different platforms. TL;DR If I wanted TOTP support, I would of got it setup but that's not what I'm asking here and no one seems to understand that.

You can only use it with Blesta in TOTP forum. Which defeats the whole purpose of having it.

I still don't see why implementing the "native" Yubikey support is being pushed off. 1 TOTP instance requires a slot in the Yubikey, why would I want to burn up the last slot in my Yubikey for that when I can use Authy in Chrome (which defeats the point of 2FA). Yes I can make myself go get my phone or tablet all the time but I'm lazy. The Yubikey is a simple device that someone *has* and a password is something one *knows*. Now that I recently got the Yubikey NEO, I can program it with a PGP key and use it as a local smartcard for domain use or even make my own hardware based personal SSH key. The reason I bring that up is because that's a more universal purpose reason to use a slot instead of just a single TOTP instance. Before someone brings up the argument saying that it's not secure, if you use LastPass, you're trusting your passwords (and possibly other data) in "the cloud" already. The Yubikey OTP has been around since 2008, it's now 2015. A whole 8 years have passed and it hasn't been breached. Since the Yubikey will not give out it's 128-bit AES key, the only option is to breach the company anyways. See page 16 of this PDF and read on about how the technology works (https://www.grc.com/sn/sn-143.pdf). (It's a transcript of an old Security Now! podcast episode.)

https://github.com/Yubico/php-yubico 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.)

Like I said in my other post "What I would like to do is sync it up to the clients account but it throws the same error." and I did uncheck the "Use Module" option. I should mention that the other 3 tabs say "This information is not yet available."

The one being registered is sctn.us, I was able to manually register it for the client directly in the resellerclub control panel and it's working fine. What I would like to do is sync it up to the clients account but it throws the same error. If it makes any difference I'm on version 3.1.3, PHP 5.4, CentOS.

As I said before (twice), resellerclub (logicboxes).

I'm trying to register a .us domain using the resellerclub module and I get this. The client has put down that he is a U.S. citizen and the purpose is personal. The URL is /admin/clients/editservice/54/199/ . All I have to do to produce this error again and again is just by clicking the activate button. The cron is unable to register it on its own and the resellerclub account is working fine for everything else. -Ryan

I believe what John was trying to say earlier is that Inertia Networks submitted its domain name (inertianetworks.com) to be put on the "Preloaded HSTS List", meaning that the browsers that support this feature will know to connect to the subdomains and the domain (inertianetworks.com) itself using ONLY SSL or die trying. The enforcing in the browser directly happens in Chromium, Chrome, Safari (Mavericks OS X 10.9), Firefox 26 (that I know of) and Opera. If you're thinking I missed Internet Explore, I did not, because not a single version of IE (including the ones in Windows 8) does not enforce the list. The same may be for the browsers on iOS & Android.

Bump.

I would like to see some sort of DNS implementation in Blesta or at least a details section under a package stating the username, password and management link like regular cPanel hosting. I currently have the PowerAdmin (for PowerDNS with DNSSEC enabled) frontend setup and I was going to give the Universal Module a whirl so I just made the dummy package and then I realized that the client could not see a set username, password and management link like trying to access a cPanel account. I also wouldn't mind seeing this for cPanel DNS as well. https://github.com/poweradmin/poweradmin https://www.powerdns.com/ https://github.com/PowerDNS/pdns