Higher Logic, Password Security, and You

By George Stocker posted Aug 14, 2014 12:22 PM


Recently, Hackers reportedly hacked over 1.2 Billion usernames and passwords, and acquired over 500 Million email addresses. At this point, it's not known which websites were hacked, or how those passwords were stored.  There is a good probabilty that anyone reading this is affected in some way by this breach.

In the case of Higher Logic, the vast majority of our clients use SSO to sign in to their Connected Community site.  When you sign in to your Connected Community site with SSO, we don't handle your password. We don't store it, and we don't know it.  We are sent a temporary token that links your Connected Community user to your AMS Login. Sometimes this token is cookie based, other time it's through industry standard authentication techniques like OAuth.  This token only lasts as long as your session lasts, and is regenerated each time you log in (your AMS settings notwithstanding).  

For our clients that do not use SSO; we currently hash passwords using an industry standard cryptographic hashing algorithm.  When a password is hashed, it is impossible to revert the result into the original password.  We monitor for attack vectors and actively work to ensure that our system is secure.  We take the security of your personal information seriously. 
We believe in the principle of least privilege, and protect against unauthorized access through multiple layers, including two-factor authentication in AWS. 

When the Center for Internet Security write a white-paper about internet security (PDF), they found out that 60% of people use the same password for multiple logins. By itself, this is worrying, but when your email often holds information about what other sites you use (Forgotten password reset links especially), it becomes much worse. Framed in that context, this breach becomes much more serious than just an email breach. It then becomes a breach into a large aspect of our lives.

There are some steps that you can take to protect yourself and your information online.

  • Don't use the same login/password combination for critical sites and non-critical sites. Consider any site that holds personally identifiable information that can be used to effect financial change as a 'critical' site and ensure you use a different password for those sites. 
  • Enable Two-Factor authentication if your Email provider offers it.  It ensures that even if someone has your password, they need your smartphone as well in order to log in as you.
  • Use passphrases where possible instead of passwords.  This XKCD comic explains the concept succinctly.  The gist is that a passphrase is a long sequence of easily memorable words; which takes a lot more effort for a computer to brute-force than an 8 character password with special characters and mixed-case lettering.
  • Talk to your IT department and websites you use. Ask them how your passwords are stored. Are they hashed? Are unique salts used for each hash? Do they use a secure hashing algorithm?  This is important to know.
  • If the answer to any of these questions is 'no', then that's a sign that your credentials are less secure in their hands than they otherwise should be.
  • Change any password that is linked to a site that contains critical information.
  • Invest in a Password Manager, such as LastPass or 1Password. 

While there is no foolproof way to be totally secure online, following these steps will help ensure that you've done everything you can to keep your personal information secure.




Aug 15, 2014 03:31 PM

I would like to see the "Principle of least privilege" for the context of users put into place for Microsite community admins in the future. Currently I can see the principle of least privilege applied for the processes/programs of Higher Logic but not for permission levels/users. I find that giving a user administrative privileges that span across the WHOLE Microsite is quite scary when all that user needs to administrate is the Events module. Multiple permission levels have been asked for quite often and I believe that is truly the answer to the "Principle of least privilege" in the context of users.

Aug 15, 2014 12:13 PM

For anyone who isn't familiar with the term, a SQL injection attack is where an attacker types in a SQL command through user input, and is able to get the Database to execute that command. It has been popularized in this XKCD Comic: .
A SQL Injection attack requires that end users are able to input commands as arbitrary strings and have those strings be executed as commands by the Database.
Using parameterized queries everywhere a user could input a arbitrary string protects against SQL injection. It's the 'built in' protection against SQL injection and has been around for a very long time. There are additional things developers can do to protect against SQL Injection attacks:
For our part, we validate user input using built in ASP.NET tools, as well as use parameterized queries (also provided for by Microsoft's .NET framework).
I checked the code that you're referring to, and all of it follows standard security practices for protecting against SQL injection attacks.
As always, if you have reason to believe that any of your data is vulnerable to a SQL injection attack or any other vulnerability, let us know through the support channels.

Aug 15, 2014 08:01 AM

We heard there was a SQL injection that could affect some of the files we store in our community (MOAA Connect) if they reside in a SQL database. Do you have any information on the security of items like that in HigherLogic? Thanks!!