Password Resets in the Enterprise

Password Reset May Seem Like A Simple Task, But Performing It Successfully Is Integral To Account Security. 

We've all had to reset a password at one point or another. The process can be somewhat tedious, especially when you want to get into an account quickly; however, it's important to look past this minor annoyance, and understand why it is in fact a very important piece to the account security puzzle.

When Is Password Reset Required?

Typically, a password reset is done when a user is not able to log into one or more applications - either they forgot their password or it has expired. To construct a secure password reset policy, businesses need to decide:

• Who should have password reset privileges?

• Should password reset privileges apply to all users, a specific group of users or an individual user account?

Why Is Having A Secure Password Reset Process Important?

Having a secure password reset process is crucial for mitigating IT security risks in an enterprise environment. Password resets in an enterprise environment are unique, because a user often has accounts on several applications. This requires users to know and maintain credentials for each individual application, and if the standard protocol for password reset is not secure, the risk of passwords being lost, stolen or compromised increases. 

What Does A Secure Password Reset Process Look Like? 

For enterprise environments, password reset typically follows the progression in the diagram below: 

What Are Causes For Security Concerns? 

The part of any password reset process that causes several IT security concerns is how to definitively confirm that the source of the request is the owner of the account. Is the appropriate user asking to create a new password or is someone attempting to hack into the account? Another concern is how to send the temporary password to the owner of the account. If either concern is not addressed, any data accessible in an account that had a password reset is not secure.

How Are These Concerns Mitigated?

The specifications for how to validate a password reset request should include gathering information known only to the owner of the account, such as security questions. To further verify the request, any contact information in the account should also be used to confirm that the requester is also the owner of the account. 

To reduce security risks even more, it is best to have the time between a password reset and the next user login to be as brief as possible. This can be done by emailing the user a temporary password reset link that expires after a certain period of time. 

Note: In enterprise environments this option may not always be available if users do not have a secondary email - the user’s primary email account could be an application that they are not able to access.

If the user contacted a help desk or if they are not able to access their email account, another possible option is resetting the password while on a call with the user, then having the user set their own password. Both options have the advantage of encouraging the user to set their new password as soon as possible.

An IAM product such as Oracle Identity Manager or Forgerock OpenIDM can be used to configure self-service password resets for users - recover accounts without contacting the help desk. Self-service Password Resets can reduce the amount of help desk calls, but may not always be the best option depending on how your organization confirms the owner of an account.

For more information on this post or any of our services or offers, contact us today.

---

PROFESSIONAL SERVICES - SYSTEMS ENGINEER

Migrating Passwords with Virtual Directories

When Does Password Migration Get Complicated? 

LDAP Directories are the backbone of many enterprise IAM infrastructures, containing user data for authentication services. This user data contains sensitive information, such as passwords stored using various hashing methods. This often becomes a problem when migrating data from a legacy Directory Server to a newer Directory Server.

Migrating from a legacy Sun Directory Server to Oracle Directory Server (ODSEE) 11g or Oracle Unified Directory (OUD) 11g is fairly straightforward as far as user passwords go. They all use compatible hashing methods and, using replication, give a great deal of flexibility with data migration.

Password migration becomes more complicated when moving from another vendor Directory, such as eDirectory or Microsoft Active Directory. While the majority of user data can be extracted, sometimes with quite a bit of massaging to get it to conform to the schema, passwords may not be possible to migrate due to incompatible hashing methods. One solution is to migrate data without the password, requiring all users to change their password after ‘go live’ with the new Directory Server. This is not always an acceptable solution to the business, but a ‘seamless’ solution must be found.

Another more attractive solution is using an LDAP Proxy Server, such as Oracle Virtual Directory (OVD) or OUD’s proxy server functionality. LDAP Proxy Servers, often referred to as Virtual Directories, can intercept LDAP requests and perform operations with custom Java plugins. These plugins can be used as a method to intercept bind requests and migrate passwords from one Directory to another.

The above diagram shows a simple flow of such a process.

The LDAP client performs its normal bind operation during authentication.
The proxy server intercepts the bind request, which contains the username and password. The plugin performs a search for that user, checking for a custom attribute that is defined (such as passwordMigrated). If the password has been migrated, a normal bind is performed, which attempts to authenticate the user.

If the password has not been migrated, the Proxy server will attempt to bind to the legacy LDAP server using the user’s credentials.

If the bind attempt is successful, the plugin has the correct password and writes that password into the new LDAP Server and updates the passwordMigrated attribute, returning a successful authentication to the client.

One caveat to keep in mind is performance. LDAP Directory Servers are designed to deliver high performance, especially in regards to authentication requests. Adding an additional layer to intercept requests does add in a bit of overhead. While this can be negligible and not apparent to an end user in a smaller environment, a larger environment with high throughput can experience some noticeable overhead. It is important to architect the Proxy Server layer accordingly. Proxy servers typically cannot process the same throughput as backend Directory Servers. This can be achieved by horizontally scaling the Proxy Server layer, if necessary.  

This solution will migrate passwords with a ‘frictionless experience’ to the end user. This is generally an interim solution for a specified period of time to capture the majority of users until the legacy system is retired. Users that do not perform an authentication during this time will need to change their password after it is removed.

Hub City Media has implemented this method and many other virtual Directory solutions. Please contact us to schedule a discovery session.

---

PROFESSIONAL SERVICES - SENIOR ARCHITECT

 

password123456: Avoiding Poor Password Practice

Are You Committing A Password Faux Pas?

It seems as if we’ve been hearing about the “end of passwords” every year for decades now, especially due to recent hacks splashed across the news. Innovations including Single Sign-on, Multi-factor Authorization, Biometrics and Google’s Trust API  have been developed as “password killers” to rid us of the nuisance of remembering passwords. Password management systems, such as 1Password, have become a useful tool to store the increasing number of account passwords we own these days, although frankly, many end users are either unaware or unwilling to put in the extra time and effort to use them. In a 2015 survey of 1,000 consumers,  only 8% used a password manager. 

Despite limitations of passwords, the “end of passwords” is not on the horizon. Passwords are the cheapest and most versatile data security method to deploy. Many applications, including Identity Management solutions, utilize passwords for administrators and end users alike. Newer authentication methods either combine with passwords, such as RSA Tokens or Smart Cards, or externalize the process while still using a password outside the application, such as Kerberos or SAML Federation. Until we truly see the “end of passwords,” following good password practices will remain as the key defensive front line protecting users and organizations from security breaches.

Quality password practice is achieved by setting a strong password policy and communicating how to create secure passwords to end users. It is of the utmost importance to show the best way to create passwords without simply satisfying minimum requirements. In this vein, coupling a custom password policy with a notification, sent to users upon creating or updating their password, increases the policy’s effectiveness.

While more applications are beginning to enforce stronger password policies, we can observe through recent password data that many users are still using unsafe passwords. Even today, the two most common passwords are “password” and “123456”.

Poor user password choice was exemplified in one of the most infamous hacks in recent memory. The LinkedIn leak of 2012 provides an interesting window into what people consider “secure” for an account they do not want to fall into the wrong hands.

At the time of the security breach, LinkedIn had a lax password policy, allowing six-character passwords with no required complexity. Facebook’s Mark Zuckerburg was among the affected, as the hack exposed that not only was Zuck using the simple password “dadada” for LinkedIn, but he was also using that same password for his Pinterest and Twitter accounts. We also learned that more than one million LinkedIn users chose “123456” as their account password, which is still the second most popular password in use today. The simplicity alone of such passwords is disturbing to those in the security industry. Perhaps even more concerning is that these users never learned one of the more important lessons from the 30-year old comedy classic Spaceballs (the other being that everything that happens now, is happening now!).

When setting policy, password length must be considered, knowing each extra character adds more security. Best practices show that password length should, at a minimum, be between 12 and 15 characters. Unfortunately, remembering lengthy passwords can be difficult. Many people meet today’s common password policies by starting with an upper-case letter, followed by a string of lowercase letters, and ending with numbers and special characters. 

Such patterns are well known to sophisticated password hackers, making passwords such as “Helloworld12!” nearly as strong as “123456.” The National Institute for Standards and Technology (NIST) has released new password guidelines, suggesting that we do away with composition rules and give the end user more freedom in password selection. Password length is more important than a shorter string of varying types of characters and should not have an artificial ceiling. Let the user create a password up to 64 characters if they so desire!

There are several ways to create strong, lengthy passwords. A “passphrase” can be taken from a favorite movie or book, or can be created using the first letters of the words of a catchphrase the user knows. For example, the phrase “The New York Mets will win the 2017 World Series!” becomes the password “TNYMwwt2017WS!”. Other methods include combining two weak passwords into one strong one, for example “Password123” and “DaBears” becomes “DaPassBearsWord123”, or doubling some or all of the letters: “Welcome1!” becomes “WweLlCcoMme11!!”. These “passphrases” also have the added benefit of being easier to remember than shorter, more complex passwords.

Using Mark Zuckerburg as an example again, it is important to remind users to never use the same password for more than one account, application or service. The tendency for users to reuse the same password is one of the primary ways hackers are able to compromise systems by simply using a hacked user login from another source. Just this past month, Spotify took the initiative to force their user base to reset their passwords as a preventative means of protection from the most recent data breaches outside Spotify and across the Internet.

Remember, passwords will never be a bulletproof security solution. When human error is involved, there will always be the opportunity for misuse. Until cheap and ubiquitous identity kevlar is created, following the password selection methods outlined here, as well as presenting these ideas to the user base, can provide a stronger defense.

Citations:
Henry, Alan. LifeHacker. “Five Best Password Managers.” January 11, 2015
http://lifehacker.com/5529133/five-best-password-managers

Rubenking, Neil J. PCMag. “Survey: Hardly Anybody Uses a Password Manager.” March 3, 2015
http://securitywatch.pcmag.com/security-software/332517-survey-hardly-anybody-uses-a-password-manager

Condliffe, Jamie. Gizmodo. “The 25 Most Popular Passwords of 2015: We're All Such Idiots.” January 19, 2016
http://gizmodo.com/the-25-most-popular-passwords-of-2015-were-all-such-id-1753591514

Hackett, Robert. Fortune. “Here Are the Most Common Passwords Found in the Hacked LinkedIn Data.” May 18, 2016
http://fortune.com/2016/05/18/linkedin-breach-passwords-most-common/

Geekologie. “Dadada, Really?: Mark Zuckerberg Gets Social Media Accounts Hacked, Password Leaked.” June 6, 2016
http://geekologie.com/2016/06/dadada-really-mark-zuckerberg-gets-socia.php

Brecht, Daniel. Infosec Institute. “Password Security: Complexity vs. Length.” December 8, 2015
http://resources.infosecinstitute.com/password-security-complexity-vs-length/

Wisniewski, Chester. Naked Security by Sophos. “NIST’s new password rules – what you need to know.” August 18, 2016
https://nakedsecurity.sophos.com/2016/08/18/nists-new-password-rules-what-you-need-to-know/

Cox, Joseph. Motherboard. “After Breaches At Other Services, Spotify Is Resetting Users' Passwords.” August 31, 2016
http://motherboard.vice.com/read/spotify-passwords-reset-security-precaution