I was planning to use uLogin but decided not to. I thought I might give some feedback as to why that is.
1.) One of the Installation Checks, "PHP on this system supports Blowfish?" gives me an error. This is despite the fact that according to phpinfo(), blowfish is indeed supported under mcrypt.
2.) For the "Are pages using uLogin redirected to SSL?" check, the tooltip says that "uLogin encrypts passwords serverside, so to ensure a secure password transmit from the client, an SSL-secured connection is necessary". Obviously SSL is the best solution, but for sites where this is not cost-effective it would still be desirable to have client-side hashing of the password before it is transmitted.
Additionally:
i.) You mention somewhere that you can use emails for usernames if you want, since uLogin makes no distinction. It would be helpful to include the 'plus' symbol (+) in UL_USERNAME_EXTRA_CHARS so that a default install of uLogin would support emails (+ is a valid email character).
ii.) The installCheck.php page throws up a bunch of warnings for me:
Strict Standards: DateTime::__construct() [datetime.--construct]: It is not safe to rely on the system's timezone settings. Please use the date.timezone setting, the TZ environment variable or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in redacted/ulogin/pdo/PdoSessionStorage.inc.php on line 14
Warning: session_start() [function.session-start]: Cannot send session cookie - headers already sent by (output started at redacted/ulogin/pdo/PdoSessionStorage.inc.php:15) in redacted/ulogin/session.inc.php on line 71
Warning: Cannot modify header information - headers already sent by (output started at redacted/ulogin/pdo/PdoSessionStorage.inc.php:15) in redacted/ulogin/session.inc.php on line 160
All the best!
Last edit: Mr Marbles 2012-10-31
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1.) The algorithm used for password hashing in bcrypt is derived from blowfish and is called eksblowfish. mcrypt supports blowfish for encryption, but uLogin needs bcrypt for hashing and mcrypt cannot be used. So the test result that you see is correct, but you are right that the test's name is somewhat misleading.
2.) Client-side hashing without SSL is much more susceptible to man-in-the-middle attacks than SSL. Furthermore, hashing in the browser does not protect potentially sensitive information trasmitted over the internet after the user has logged on. An SSL connection also protects cookies which is vital for the user session's security. You can get totally free and 100% valid SSL certificates (for example from StartSSL) that do not generate a warning, so I do not see how SSL can be "not cost-effective". As a result, currently I see absolutely no reason to implement client-side hashing. You really should get an SSL certificate if you value security. It is free and easy to install.
3.) You are right. '+' will be added to the default set in uLogin 0.7. I see no harm in adding '+', but e-mail syntax would allow a lot more characters many of which I will never allow as a default setting. This is why UL_USERNAME_EXTRA_CHARS is a configuration variable, so that library users can fine tune it to individual needs.
4.) You get those warnings because you did not set PHP's default timezone. The first warning is emitted because of the missing setting in your machine, and the other two warnings are a result of the first (kind of like an avalanche effect). Fix your timezone and they should all go away. This is not uLogin's fault. Set date.timezone in your php.ini, or if you do not have access to it, use date_default_timezone_set().
Cheers
Last edit: ultim 2012-11-02
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
2.) I know that client-side hashing without SSL is susceptible to MITM attacks, but it's still better than nothing as it protects the user's password if it is compromised, in case they use the same password on multiple sites. Also, what about situations where a MITM attack forces the client to use a plain http connection, or where an employer uses their own SSL certificate to sign third party websites? In that situation, SSL is 'removed' and a plaintext password is sent. With client-side hashing, while the attacker would be able to login, he wouldn't know the password. With regards to cost, don't forget that to have SSL, your server needs a unique IP which typically costs extra on shared hosting.
4.) Sure, I guessed as much. But I tried it on a very popular shared hosting provider, so it might be worth putting a default timezone setting into uLogin's config.
Last edit: Mr Marbles 2012-11-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
2.) As I said, without SSL you are more susceptible to MITM. I never said on purpose that with SSL you are completely safe. Especially if you are using HSTS (which uLogin has support for by the way), HSTS makes it even harder for the attacker to do MITM compared to "plain SSL". Client support for HSTS is not yet uniformly available but is something that you can safely turn on serverside, clients that do not support it will still work correctly without the added security. But even without HSTS you need greater efforts to MITM an SSL connection than no SSL at all. http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
And to repeat myself, SSL has more benefits than just password encryption, like protecting cookies (thus also your session) and website content too.
4.) Setting the correct timezone for your whole PHP environment is not the job of a security library. Just because uLogin calls date/time functions does not mean that uLogin should set your timezone.
Last edit: ultim 2012-11-15
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi guys,
I was planning to use uLogin but decided not to. I thought I might give some feedback as to why that is.
1.) One of the Installation Checks, "PHP on this system supports Blowfish?" gives me an error. This is despite the fact that according to phpinfo(), blowfish is indeed supported under mcrypt.
2.) For the "Are pages using uLogin redirected to SSL?" check, the tooltip says that "uLogin encrypts passwords serverside, so to ensure a secure password transmit from the client, an SSL-secured connection is necessary". Obviously SSL is the best solution, but for sites where this is not cost-effective it would still be desirable to have client-side hashing of the password before it is transmitted.
Additionally:
i.) You mention somewhere that you can use emails for usernames if you want, since uLogin makes no distinction. It would be helpful to include the 'plus' symbol (+) in UL_USERNAME_EXTRA_CHARS so that a default install of uLogin would support emails (+ is a valid email character).
ii.) The installCheck.php page throws up a bunch of warnings for me:
All the best!
Last edit: Mr Marbles 2012-10-31
Hi,
1.) The algorithm used for password hashing in bcrypt is derived from blowfish and is called eksblowfish. mcrypt supports blowfish for encryption, but uLogin needs bcrypt for hashing and mcrypt cannot be used. So the test result that you see is correct, but you are right that the test's name is somewhat misleading.
2.) Client-side hashing without SSL is much more susceptible to man-in-the-middle attacks than SSL. Furthermore, hashing in the browser does not protect potentially sensitive information trasmitted over the internet after the user has logged on. An SSL connection also protects cookies which is vital for the user session's security. You can get totally free and 100% valid SSL certificates (for example from StartSSL) that do not generate a warning, so I do not see how SSL can be "not cost-effective". As a result, currently I see absolutely no reason to implement client-side hashing. You really should get an SSL certificate if you value security. It is free and easy to install.
3.) You are right. '+' will be added to the default set in uLogin 0.7. I see no harm in adding '+', but e-mail syntax would allow a lot more characters many of which I will never allow as a default setting. This is why UL_USERNAME_EXTRA_CHARS is a configuration variable, so that library users can fine tune it to individual needs.
4.) You get those warnings because you did not set PHP's default timezone. The first warning is emitted because of the missing setting in your machine, and the other two warnings are a result of the first (kind of like an avalanche effect). Fix your timezone and they should all go away. This is not uLogin's fault. Set date.timezone in your php.ini, or if you do not have access to it, use date_default_timezone_set().
Cheers
Last edit: ultim 2012-11-02
2.) I know that client-side hashing without SSL is susceptible to MITM attacks, but it's still better than nothing as it protects the user's password if it is compromised, in case they use the same password on multiple sites. Also, what about situations where a MITM attack forces the client to use a plain http connection, or where an employer uses their own SSL certificate to sign third party websites? In that situation, SSL is 'removed' and a plaintext password is sent. With client-side hashing, while the attacker would be able to login, he wouldn't know the password. With regards to cost, don't forget that to have SSL, your server needs a unique IP which typically costs extra on shared hosting.
4.) Sure, I guessed as much. But I tried it on a very popular shared hosting provider, so it might be worth putting a default timezone setting into uLogin's config.
Last edit: Mr Marbles 2012-11-14
2.) As I said, without SSL you are more susceptible to MITM. I never said on purpose that with SSL you are completely safe. Especially if you are using HSTS (which uLogin has support for by the way), HSTS makes it even harder for the attacker to do MITM compared to "plain SSL". Client support for HSTS is not yet uniformly available but is something that you can safely turn on serverside, clients that do not support it will still work correctly without the added security. But even without HSTS you need greater efforts to MITM an SSL connection than no SSL at all.
http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
As for SSL needing a unique IP, this is simply not true. SNI is a six year old technology in servers and browser clients that allows you to have one certificate per virtual host on the same IP. It has been around long enough to say that you do not need to worry about its availability. Only IE6 and IE7onXP users are not going to support it, but that is less than 1% of all users.
http://www.w3schools.com/browsers/browsers_explorer.asp
http://en.wikipedia.org/wiki/Server_Name_Indication
http://en.gentoo-wiki.com/wiki/Apache2/SSL_and_Name_Based_Virtual_Hosts
And to repeat myself, SSL has more benefits than just password encryption, like protecting cookies (thus also your session) and website content too.
4.) Setting the correct timezone for your whole PHP environment is not the job of a security library. Just because uLogin calls date/time functions does not mean that uLogin should set your timezone.
Last edit: ultim 2012-11-15