Category Archives: passwords

Cracking the Passwords of Early Internet Pioneers

Lots of them weren't very good:

BSD co-inventor Dennis Ritchie, for instance, used "dmac" (his middle name was MacAlistair); Stephen R. Bourne, creator of the Bourne shell command line interpreter, chose "bourne"; Eric Schmidt, an early developer of Unix software and now the executive chairman of Google parent company Alphabet, relied on "wendy!!!" (the name of his wife); and Stuart Feldman, author of Unix automation tool make and the first Fortran compiler, used "axolotl" (the name of a Mexican salamander).

Weakest of all was the password for Unix contributor Brian W. Kernighan: "/.,/.," representing a three-character string repeated twice using adjacent keys on a QWERTY keyboard. (None of the passwords included the quotation marks.)

I don't remember any of my early passwords, but they probably weren't much better.

Does poor password hygiene still hamper your ability to achieve high security standards?

While more businesses are investing in security measures like multifactor authentication (MFA), employees still have poor password habits that weaken companies’ overall security posture, according to LastPass. Given that stolen and reused credentials are linked to 80 percent of hacking-related breaches, businesses must take more action to improve password and access security to make a big impact on risk reduction. “Securing employee access has never been more important and unfortunately, we see businesses ignore password … More

The post Does poor password hygiene still hamper your ability to achieve high security standards? appeared first on Help Net Security.

Password Mistakes You and Your Employees Are (Probably) Making

Your employees might already be aware of a few password security practices. But are they actually following the latest recommendations? In fact, are you aware of what makes up a strong password policy? Both you and your employees could be (unknowingly) making common password mistakes and applying antiquated password security guidelines. So, keep on reading to make sure you’re in alignment with the most recent password requirements.

In this article, I’m going to share with you pieces of advice on how you can prevent the most frequent password mistakes and how you can create a strong password policy for your organization.

Some of the points covered in this article may seem controversial at first glance and completely out of sync with the password security rules that we’ve all grown accustomed to by now. Nonetheless, they are supported by the latest password guidelines released by The National Institute of Standards and Technology (NIST) – NIST 800-63-3: Digital Identity Guidelines. For those unfamiliar with this institution, to give you a quick background, they are a non-regulatory federal agency within the US Department of Commerce, whose guidelines oftentimes have built the foundation of the security industry’s standards.

The NIST paper isn’t new. In fact, it was released more than two years ago. Yet, many organizations still seem to be ignoring it and this is why we’ve decided to bring it into the spotlight and present their instructions on password security.

What are the Best Practices for Creating a Strong Password Policy?

Older NIST password security guidelines required enforcing policies such as using highly complex passwords, changing them regularly, and forbidding password reuse. However, their newest guide is based upon a quite radically different approach.

Does this mean that your employees should be setting their passwords to “Password1234” and never change them?

Of course not. This new approach is focused on making password management easier and more user-friendly. It has been created based on studies showing that very strict password policies only lead to poorer password habits.

Below you will find password security recommendations that will make it slightly easier for your employees to comply with and for you to keep your business secured. So, here is what you should do to promote a healthy password security management among your employees based on NIST’s recommendations:

#1. Stop asking your users to change their passwords on a predefined schedule

First of all, your users will be thankful that they won’t have to create new passwords and remember the new ones every 90 days (or even more frequently). Most of them do not even change their passwords entirely anyway and only add an extra character at the end every time they are required to modify them. So how does this practice reinforce password security?

Periodic password resets have been created in order to reduce the period of time a system is exposed due to an account potentially being compromised. But why change passwords if there is no suspicious of a breach? Useless password resets burden users and create additional tasks for sysadmins if, for instance, your employees forget them and require password resets.

So, how often should your users change their passwords?

According to NIST, passwords should NOT be changed unless there is evidence of a data breach or any reason which shows a specific account has been compromised. In other words, only when there is a possible danger related to an account should password resets be mandatory, rather than making your users change their passwords on a predetermined schedule.

However, it’s really important for you to provide your specialists with the proper cybersecurity tools to monitor users’ activity and identify compromised accounts in real-time.

Microsoft has removed the password expiration policies from their Windows 10 security baseline. Here is what they wrote on their blog:

Periodic password expiration is a defense only against the probability that a password (or hash) will be stolen during its validity interval and will be used by an unauthorized entity. If a password is never stolen, there’s no need to expire it. And if you have evidence that a password has been stolen, you would presumably act immediately rather than wait for expiration to fix the problem.


Periodic password expiration is an ancient and obsolete mitigation of very low value, and we don’t believe it’s worthwhile for our baseline to enforce any specific value. By removing it from our baseline rather than recommending a particular value or no expiration, organizations can choose whatever best suits their perceived needs without contradicting our guidance. At the same time, we must reiterate that we strongly recommend additional protections even though they cannot be expressed in our baselines. 

Aaron Margosis, Microsoft Security Guidance blog

#2. Encourage your users to select long and easy to recall passphrases

It’s time to move beyond complicated passwords based upon highly complex construction rules. It will be much easier for people to remember phrases that actually make sense to them instead of memorizing strings of completely random characters. However, the passphrase should not be something too obvious and tightly related to something which defines them as individuals (and might also be at hand for malicious hackers on social media).

Traditional PasswordsNIST Passwords
Highly complex string of random characters

Example: *Ajh{df0s_SF(8aLsV9(fkj@<;sK+
Long and memorable passphrases

Example: “It’s so easy to create strong passwords with NIST’s guidelines!”
Example: “I’m really looking forward to this year’s holiday season.”

Of course, longer passwords composed of various types of characters are more difficult to decipher from a cryptographic standpoint. Nonetheless, traditional password construction rules make them harder to remember and seem to only be making users end up choosing insecure passwords. According to NIST, IT systems should allow a minimum of 8 characters and a maximum of 64 characters and include all kinds of characters including punctuation and spaces. The minimum required password length proposed by NIST is still 8 characters.

Sometimes, many password-related attacks are not affected by password length and complexity at all. Unfortunately, complicated passwords completely fail when it comes to social engineering attacks, credential stuffing, keyloggers, or phishing/spear phishing, but this is a whole different subject that I’m not going to dive into in this article.

#3. Implement multi-factor authentication

NIST’s guidelines also advise on the implementation of multi-factor authentication, which can considerably increase security without further burdening users with complex requirements. Multi-factor authentication encompasses a wide range of authentication technologies, such as biometrics, smartphone apps/codes received via text messages, or token devices which will provide an additional layer of security.

#4. Cross-check passwords with password dictionaries

A password validation dictionary that contains commonly used and insecure passwords is also necessary. This way, unsafe passwords will be automatically rejected by your system.

Let’s say a user creates a password of the minimum required length that also happens to be highly insecure. And let’s suppose that the password will not be prohibited by the restricted passwords list, yet the chosen password can be easily hacked.

Since NIST does not provide a list of “bad” passwords, organizations should create their own notorious passwords databases and constantly update them. According to the paper featured in the ISACA Journal, the open-source repository “SecLists” on GitHub or the password validation tool “NIST Bad Passwords” can be good starting points for you to create your own internal password dictionary.

Also, the same publication advises against forgetting about context-specific passwords. For instance, you should take into account the usage of a user’s own name, the company’s name or anything closely related to the organization they are part of.

In essence, a generic password dictionary will not be able to block anything related to an individual user, which brings us to the next point.

#5. Constantly revisit and update your password policy

Unfortunately, a one-size-fits-all approach when it comes to password policies is not advisable. Every organization must create a policy that covers custom password restrictions and revise them constantly. What’s more, if a data breach ever takes place, all compromised passwords must be included in the forbidden passwords list.

#6. Train your users

Last but not least, make sure that in your cybersecurity training sessions you teach your employees how to form passwords based on the most recent NIST guidelines. After they’ve been properly trained, they should be able to correctly identify which passwords are secure and which ones are not.

Key Takeaways

  • Recommended Password Length— 8-64 characters.
  • Character types — All available characters are allowed and encouraged.
  • Multi-factor Authentication — Highly encouraged.
  • Password Construction — Long passphrases instead of complex passwords are recommended. There must be no match between them and the password dictionary.
  • Password Reset Frequency — Only if the password is forgotten or at first signs of compromise.

Examples of Password Mistakes Made by Your Employees

I’ve already gone through password construction rules, but there are more best practices in regard to password security that your employees should follow. They may seem obvious for most people, however, be certain you still include them in your cybersecurity training sessions as a reminder.

#1. Reusing the same password

Your users may be using the same passwords for different business-related accounts – for instance, for their email login account and an online third-party service where they registered with their corporate email address. If that specific website gets hacked, chances are that cyber-attackers will use their passwords to try to log into their accounts. This tactic is called credential stuffing and is a practice highly employed by cybercriminals.

What’s more, another mistake can be reusing a password they’ve set up for a personal account on their business account, since the same type of attack could easily happen.

#2. Sharing passwords

Needless to say, your employees’ passwords must always remain confidential. They should never share them with other employees or members outside of your organization.

#3. Not using a password manager

We can all agree on the fact that remembering a different password for each account is a hassle, especially for third-party websites. However, when using password managers, your employees will only need to remember the one used to access their password manager, where all their passwords are stored.

#4. Skipping multi-factor authentication

Multi-factor authentication can dramatically reduce fraudulent login attempts, so make sure that you’ve set up this option on your organizations’ accounts and that your people do not have the possibility to skip it!

#5. Changing a single character of the password after you’re suspecting their account has been compromised

If cybercriminals have managed to guess their password, if the new one is just slightly different, chances are the password is going to be hacked once again. So, make sure your users understand and apply the password security guidelines presented in-depth above.

#6. Storing passwords in plain text on their devices

Your employees may be keeping their passwords in plain text and that is, of course, a terrible practice, since the passwords could be easily accessed by malicious actors. Thus, they should stay away from storing them on their phones, spreadsheets, text files, or emailing the passwords to their personal email addresses for whatever reasons.

#7. Writing them down in easily accessible places

No one should write down their passwords on post-it notes kept on their desks, hidden under the keyboard, written on their day planner, etc. The danger of insider threat might linger inside your organization.

#8. Logging into their business accounts on unsecured networks or devices.

If your employees want to connect remotely and use an open public Wi-Fi network or enter their login credentials on a personal device that is not properly secured, their connection could be left open to snooping. In this case, they should always use a VPN.


The guidelines proposed by NIST truly have the capacity to aid IT professionals to strengthen their defenses without unnecessarily burdening their users. Nonetheless, organizations that have adopted them or are considering implementing them, should completely understand the logic and approach behind. And most importantly, security professionals must first comprehend the cybersecurity risk profile of their company to create strong password policies.

What do you think about NIST’s password security guidelines? Have you already implemented them inside your organization?

The post Password Mistakes You and Your Employees Are (Probably) Making appeared first on Heimdal Security Blog.

Employees are mistakenly confident that they can spot phishing emails

While a majority (79%) of people say they are able to distinguish a phishing message from a genuine one, nearly half (49%) also admit to having clicked on a link from an unknown sender while at work, according to a Webroot survey. Further, nearly half (48%) of respondents said their personal or financial data had been compromised by a phishing message. However, of that group more than a third (35%) didn’t take the basic step … More

The post Employees are mistakenly confident that they can spot phishing emails appeared first on Help Net Security.

Passwordless authentication is here ​now​, and it is vastly superior to using a password

Mirko Zorz, Help Net Security’s Editor in Chief, recently published ​an article about the state of passwordless authentication​ that predicted a long journey before this technology is viable. We would like to share that passwordless multi-factor authentication is a reality today. Large and respected organizations, including a significant healthcare software provider, are already using this technology with great success. Here is how TraitWare has completed the journey to deliver passwordless authentication. Passwordless authentication doesn’t have … More

The post Passwordless authentication is here ​now​, and it is vastly superior to using a password appeared first on Help Net Security.

Banks, Arbitrary Password Restrictions and Why They Don’t Matter

Banks, Arbitrary Password Restrictions and Why They Don't Matter

Allow me to be controversial for a moment: arbitrary password restrictions on banks such as short max lengths and disallowed characters don't matter. Also, allow me to argue with myself for a moment: banks shouldn't have these restrictions in place anyway.

I want to put forward cases for both arguments here because seeing both sides is important. I want to help shed some light on why this practice happens and argue pragmatically both for and against. But firstly, let's just establish what's happening:

People are Upset About Arbitrary Restrictions

This is actually one of those long-in-draft blog posts I finally decided to finish after seeing this tweet earlier on in the week:

It feels wrong because 5 digits presents an extremely limited set of different possible combinations the password can be. (There's something a little off with the maths here though - 5 digits would only provide 100k permutations whereas 5 characters would provide more in the order of 1.5B.)

That said, Westpac down in Australia certainly appears to be 6 characters:

Which puts us well north of a billion possibilities again. Want more? CommBank will give you 16 characters:

On the one hand, it's a damn sight more generous than the previous two banks yet on the other hand, why? And while I'm here questioning CommBank's logic, what the hell is going on with this:

Banks, Arbitrary Password Restrictions and Why They Don't Matter

1Password has an open letter to banks on precisely this because its awful advice steeped in legacy misunderstandings of both technology and human brains. That open letter is often used as a reference to persuade banks to lift their game:

So on the surface of it, the whole thing looks like a bit of a mess. But it's not necessarily that bad, and here's why:

Password Limits on Banks Don't Matter

That very first tweet touched on the first reason why it doesn't matter: banks aggressively lock out accounts being brute forced. They have to because there's money at stake and once you have a financial motivator, the value of an account takeover goes up and consequently, so does the incentive to have a red hot go at it. Yes, a 5-digit PIN only gives you 100k attempts, but you're only allowed two mistakes. Arguably you could whittle that 100k "possibilities" down to a much smaller number of "likely" passwords either by recognising common patterns or finding previously used passwords by the intended victim, but as an attacker you're going to get very few bites at that cherry:

Next up is the need to know the target's username. Banks typically use customer registration numbers as opposed to user-chosen usernames or email addresses so there goes the value in credential stuffing lists. That's not to say there aren't ways of discovering someone's banking username, but it's a significantly higher barrier to entry than the typical "spray and pray" account takeover attempts.

Then there's the authentication process itself and it reminds me of a discussion I had with a bank's CISO during a recent workshop. I'd just spent two days with his dev team hacking themselves first and I raised the bollocking they were getting on social media due a new password policy along the lines of those in the tweets you see above. He turned to me and said, "Do you really think the only thing the bank does to log people on is to check the username and password?" Banks are way more sophisticated than this and it goes well beyond merely string-matching credentials; there's all sorts of other environment, behavioural and heuristic patterns used to establish legitimacy. You won't ever see a bank telling you how they do it, but those "hidden security features" make a significant contribution to the bank's security posture:

Then there's the increasing propensity for banks to implement additional verification processes at key stages of managing your money. For example, one of the banks I regularly use sends me a challenge via SMS whenever setting up a new payee. Obviously, SMS has its own challenges, but what we're talking about now is not just needing to successfully authenticate to the bank, but also to prove control of a phone number at a key stage and that will always be more secure than authentication alone.

And if all of this fails? Banks like ING will give you your money bank:

Now, compare all this to logging on to

Banks, Arbitrary Password Restrictions and Why They Don't Matter

How much sophistication do you think is behind those username and password fields in that vBulletin forum? Exactly, it's basic string-matching and this is really the point: judging banks by the same measures we judge basic authentication schemes is an apples and oranges comparison.

However, I disagree with banks taking this approach so let me now go and argue from the other side of the fence.

Banks Shouldn't Impose Password Limits

There are very few independent means by which we can assess a website's security posture in a non-invasive fashion. We can look for the padlock and the presence of HTTPS (which is increasingly ubiquitous anyway) and we look at the way in which they allow you to create and use passwords. There are few remaining measures of substance we can observe without starting to poke away at things.

So what opinion do you think people will form when they see arbitrary complexity rules or short limits? Not a very positive one and there are the inevitable conclusions drawn:

Hey [bank], does that 16 character limit mean you've got a varchar(16) column somewhere and you're storing passwords as plain text?

As much as I don't believe that's the case in any modern bank of significance, it's definitely not a good look. Inevitably the root cause in situations like this is "legacy" - there's some great hulking back-end banking solution the modern front-end needs to play nice with and the decisions of yesteryear are bubbling up to the surface. It's a reason, granted, but it's not a very good one for any organisation willing to make an investment to evolve things.

But beyond just the image problem, there's also a functional problem with arbitrarily low password limits:

I've been through this myself in the past and I vividly recall creating a new PayPal password with 1Password only to find the one in my password manager had been truncated on the PayPal side and I was now locked out of my account. This is just unnecessary friction.


So wrapping it all up in reverse order, arbitrary low limits on length and character composition are bad. They look bad, they lead to negative speculation about security posture and they break tools like password managers.

But would I stop using a bank (as I've seen suggested in the past) solely due to their password policy? No, because authentication in this sector (and the other security controls that often accompany it) go far beyond just string-matching credentials.

Let's keep pushing banks to do better, but not lose our minds about it in the process.