top of page
  • Writer's pictureRobert Narducci

NIST or "Need It Secured Today"

NIST or "Need It Secured Today"

What is the bane of cybersecurity? What is one of the easiest things to implement but one of the most difficult things to control? You guessed it, the lowly password. We all use them for our online banking to our Amazon Prime account. The problem is that the majority of people use simple, easy to remember passwords that are easy to guess, and easy to crack. The bad actors love this fact!

According to IBM Security, 19% of all breaches were the direct result of compromised credentials. With that said, people certainly can be the weakest link in the security chain, and this does not seem to be getting any better. Add to this problem, the proliferation of the Internet of Things (IoT), and the problem gets magnified and compounded many, many times over. Now it is estimated that this year there will be over 10 billion active IoT devices, and by 2030 there will be over 25 billion. This mere fact alone is startling, and lends credibility to the fact there needs to be more attention paid to Authentication using passwords. As the number of devices grow, so will the number of bad actors just waiting for the chance to crack the weak password, wonder around the network, and steal personally identifiable information (PII) as they see fit. To think that when this happens, and it will happen, it all could probably have been avoided with just a change of the generic password to something more robust, something more difficult to crack, something that was defined by the National Institute of Standards and Technology (NIST) standards.

To be sure, passwords out of the box are usually never changed, and if they are they are usually weak and easy to remember. There should be a forced password change that the manufacturers build in to their devices firmware that complies with NIST. As a matter of fact, NIST has a publication that speaks to this very thing. It is all outlined in SP 800-63B; Digital Identity Guidelines – Authentication and Lifecycle Management, specifically section 5. Sufficient complexity and secrecy is the key.

NIST is the defacto standard when it comes to a framework that cybersecurity can be built around. So much so, that to do business with the United States Government, an organization has to be NIST compliant. OK, so back to this password thing. What type of considerations, and requirements should be built into passwords, and how does NIST cover this? Well I am glad you asked, so let’s delve right in!

NIST calls a “memorized secret authenticator” a password or PIN. Also known as a shared secret, it makes up the basis of Symmetric Single-Factor Authentication (SFA). A shared secret is something that not only you know, but the other party knows; with the other party being your bank, Amazon, etc. It is due to this shared secret basis that it becomes critical in creating a password that is fairly “crack” proof.

These requirements are not only for the Memorized Secret Authenticator, but for the Memorized Secret Verifier. With that, the chosen “memorized secret” should be eight characters in length with all ASCII characters, and even the “space” character being acceptable to use. Further requirements can be: -Include one or more numeric digits. -Include special characters such as %, $, #, etc. -No consecutive use of numbers or letters, such as 1234, or abcd. -No reuse of passwords that have been used the past three times. -No personal information such as name, address, telephone, license number, etc. -No passwords that include words found on password blacklists. -Forced password change at least every 90 days. Verifers are required to not allow the user to store a “hint” that would be accessible to unauthorized people, and further the verifier will not prompt users to use particular types of information such as “what is the name of your first pet?”, etc. Verifiers are to use encryption, and memorized secrets are to be salted and hashed. On the authenticator side, there are many requirements such as: -Physical authenticator which provides a mechanism that can suspend or revoke the authenticator given notice from the subscriber that loss or theft has occurred. -Rate limiting which provides a set number of times a login can be attempted after consecutive failed login attempts. This helps to keep guessing attacks to a minimum. Additional things that can be required on top of rate limiting is using CAPTCHA, and yes, we all know what that is! Also, a period of time that has to be waited following the maximum number of failed login attempts.

I could go on and on with this subject, but you get the picture. At the end of the day, the role of the password in SFA is fairly weak, generally speaking. There are ways to harden the security surrounding this type of Authentication, and NIST leads the way in providing those recommendations. I recommend that you review these NIST guidelines, as you may find some recommendations that you never thought about. Remember, security is every one’s shared responsibility!

7 views0 comments

Recent Posts

See All
Post: Blog2_Post
bottom of page