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

Ubuntu, 5.4.6-1ubuntu1.2, yes I censored some data so people don't go to it or learn anything about the directory structure. The glitch I had was the define(htaccess) thing, that fixed it and Cody does not seem to realize that. Config: server { listen (port and ssl options); #listen [::]:80 default_server ipv6only=on; ## listen for ipv6 root (blesta folder); index index.php index.html index.htm; # Make site accessible from http://localhost/ server_name (site name); # Ported from Blesta's .htaccess # There are more than one way to accomplish this. # You can use try_files rather than using IF ... rewrite; location / { error_page 404 = @blesta; #IF file doesn't exist log_not_found off; # For access to install file if ($request_uri ~ "^(.*)/install.php$"){ rewrite install.php /%1/install/ redirect; } } #Core rewrite location @blesta { rewrite ^(.*)$ /index.php; } location ~ (\.pdt) { return 403; } # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000 # location ~ \.php$ { try_files $uri =404; # fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_connect_timeout 60; fastcgi_send_timeout 180; fastcgi_read_timeout 180; # Buffer settings increase to compensate for increased time/size due to SSL fastcgi_buffer_size 128k; fastcgi_buffers 4 256k; # fastcgi_busy_buffers_size 256k; fastcgi_temp_file_write_size 256k; fastcgi_intercept_errors on; # # NOTE: You should have "cgi.fix_pathinfo = 0;" in php.ini # # # With php5-cgi alone: # fastcgi_pass 127.0.0.1:9000; # # With php5-fpm: fastcgi_pass unix:/var/run/php5-fpm.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } # deny access to .htaccess files, if Apache's document root # concurs with nginx's one # location ~ /\.ht { deny all; } # serve static files directly location ~* ^.+.(jpg|jpeg|gif|css|png|js|ico|html|xml|txt)$ { expires max; } (ssl and log file stuff here) }

Hi again, I was able to install 3.0b3 from the CLI just fine and I have not been able to access Blesta at all because of a redirect issue that uses the document path in the URL for some reason. Example (http://domain.tld/linux/path/to/blesta). I tried converting the "stock" .htaccess rules and looked at https://github.com/cloudrck/blesta-nginx/blob/master/sites-available/blestav3, neither of them worked. During this whole process I have been checking the error and access logs and it seems to be the index.php script doing the redirecting because Nginx is not doing it. I do not want to use Apache2 because of the known vulnerabilities that it has and would rather use a high performance solution. I also do not want to setup a reverse proxy from Nginx to Apache2 since I don't see why it shouldn't work with any web server software. Thanks

Hi again, I have been following the documentation to do remote API calls. How would I be able to do an array for the Users-Add call and others that would need an array at a remote location? Thanks.

Hi everyone, I was curious if any new API calls were added in besides the ones listed for v2 on the main site. I would rather develop a site during the beta stages so I can go live when the final version comes out. Thanks.