Regular Expression for Password Validation

Regex to validate password strength

You can do these checks using positive look ahead assertions:

^(?=.*[A-Z].*[A-Z])(?=.*[!@#$&*])(?=.*[0-9].*[0-9])(?=.*[a-z].*[a-z].*[a-z]).{8}$

Rubular link

Explanation:

^                         Start anchor
(?=.*[A-Z].*[A-Z])        Ensure string has two uppercase letters.
(?=.*[!@#$&*])            Ensure string has one special case letter.
(?=.*[0-9].*[0-9])        Ensure string has two digits.
(?=.*[a-z].*[a-z].*[a-z]) Ensure string has three lowercase letters.
.{8}                      Ensure string is of length 8.
$                         End anchor.

Javascript regular expression password validation having special characters

Use positive lookahead assertions:

var regularExpression = /^(?=.*[0-9])(?=.*[!@#$%^&*])[a-zA-Z0-9!@#$%^&*]{6,16}$/;

Without it, your current regex only matches that you have 6 to 16 valid characters, it doesn't validate that it has at least a number, and at least a special character. That's what the lookahead above is for.

(?=.*[0-9]) - Assert a string has at least one number;
(?=.*[!@#$%^&*]) - Assert a string has at least one special character.

Regular Expression for password validation

There seems to be a lot of confusion here. The answers I see so far don't correctly enforce the 1+ number/1+ lowercase/1+ uppercase rule, meaning that passwords like abc123, 123XYZ, or AB*&^# would still be accepted. Preventing all-lowercase, all-caps, or all-digits is not enough; you have to enforce the presence of at least one of each.

Try the following:

^(?=.*[a-z])(?=.*[A-Z])(?=.*\d).{8,15}$

If you also want to require at least one special character (which is probably a good idea), try this:

^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)(?=.*[^\da-zA-Z]).{8,15}$

The .{8,15} can be made more restrictive if you wish (for example, you could change it to \S{8,15} to disallow whitespace), but remember that doing so will reduce the strength of your password scheme.

I've tested this pattern and it works as expected. Tested on ReFiddle here: http://refiddle.com/110

Edit: One small note, the easiest way to do this is with 3 separate regexes and the string's Length property. It's also easier to read and maintain, so do it that way if you have the option. If this is for validation rules in markup, though, you're probably stuck with a single regex.

Reference - Password Validation

Dilbert comic strip for Mordac, the preventer of information services

Why password validation rules are bad?

Our very own Jeff Atwood (blogger of Coding Horror and co-founder of Stack Overflow and Stack Exchange) wrote a blog about password rules back in March of 2017 titled Password Rules are Bullshit. If you haven't read this post, I would urge you to do so as it greatly mirrors the intent of this post.

If you have never heard of NIST (National Institute of Standards and Technology), then you're likely not using correct cybersecurity methods for your projects. In that case please take a look at their Digital Identity Guidelines. You should also stay up to date on best practices for cybersecurity. NIST Special Publication 800-63B (Revision 3) mentions the following about password rules:

Verifiers SHOULD NOT impose other composition rules (e.g. requiring
mixtures of different character types or prohibiting consecutively
repeated characters) for memorized secrets.

Even Mozilla's documentation on Form data validation pokes fun at password rules (page archive here):

"Your password needs to be between 8 and 30 characters long, and contain one uppercase letter, one symbol, and a number" (seriously?)

What happens if you impose composition rules for your passwords? You're limiting the number of potential passwords and removing password permutations that don't match your rules. This allows hackers to ensure their attacks do the same! "Ya but there's like a quadrillion (1,000,000,000,000,000 or 1x10¹⁵) password permutations": 25-GPU cluster cracks every standard Windows password in <6 hours (95⁸ = 6,634,204,312,890,625 ~ 6.6x10¹⁵ passwords).

xkcd
_{This StackExchange Security post extends the XKCD comic above.}

How do I validate passwords?

1. Don't create your own authentication

Stop requiring passwords altogether, and let people log in with Google, Facebook, Twitter, Yahoo, or any other valid form of Internet
driver's license that you're comfortable with. The best password
is one you don't have to store.

_{Source: Your Password is Too Damn Short by Jeff Atwood.}

2. Creating your own authentication

If you really must create your own authentication methods, at least follow proven cybersecurity methods. The following two sections (2.1 and 2.2) are taken from the current NIST publication, section 5.1.1.2 Memorized Secret Verifiers.

2.1. Follow PROVEN cybersecurity methods

NIST states that you SHOULD:

Require subscriber-chosen memorized secrets to be at least 8 characters in length.
- Jeff Atwood proposes passwords should be a minimum of 10 characters for normal users and a minimum of 15 characters for users with higher privileges (i.e. admins and moderators).
Permit subscriber-chosen memorized secrets up to 64 characters or more in length.
- Ideally, you shouldn't even put an upper limit on this.
Allow all printing ASCII (including the space character) and Unicode.
- For purposes of length requirements, each Unicode code point SHALL be counted as a single character.
Compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. For example:
- Passwords obtained from previous breach corpuses.
- Dictionary words.
- Repetitive or sequential characters (e.g. aaaaaa, 1234abcd)
- Context-specific words, such as the name of the service, the username, and derivatives thereof.
Offer guidance to the subscriber, such as a password-strength meter.
Implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts that can be made on the subscriber's account (see Rate Limiting (Throttling)).
Force a change if there is evidence of compromise of the authenticator.
Permit claimants to use paste functionality when entering a memorized secret (facilitates the use of password managers, which typically increase the likelihood that users will choose stronger memorized secrets).

2.2. DO NOT use any of the methods in this section!

The same publication also states that you SHOULD NOT:

Truncate the secret.
Permit the subscriber to store a hint that is accessible to an unauthenticated claimant.
Prompt subscribers to use specific types of information (e.g. "What was the name of your first pet?") when choosing memorized secrets.
Impose other composition rules (e.g. requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets.
Require memorized secrets to be changed arbitrarily (e.g. periodically).

There are a plethora of websites out there explaining how to create "proper" password validation forms: Majority of these are outdated and should not be used.

3. Using Password Entropy

Before you continue to read this section, please note that this section's intent is not to give you the tools necessary to roll out your own security scheme, but instead to give you information about how current security methods validate passwords. If you're considering creating your own security scheme, you should really think thrice and read this article from StackExchange's Security community.

3.1. Overview of Password Entropy

At the most basic level, password entropy can be calculated using the following formula:

$E = log2(R^L)$

In the above formula:

$E$ represents password entropy
$R$ is the number of characters in the pool of unique characters
$L$ is the number of characters in the password

This means that $R^L$ represents the number of possible passwords; or, in terms of entropy, the number of attempts required to exhaust all possibilities.

Unfortunately, what this formula doesn't consider are things such as:

Generic passwords: i.e. Password1, admin
Names: i.e. John, Mary
Commonly used words: i.e. In the English language the, I
Reversed/Inverted words: i.e. drowssap (password backwards)
Letter substitution (aka leet): i.e. P@$$w0rd

Adding logic for these additional considerations presents a large challenge. See 3.2 for existing packages that you can add to your projects.

3.2. Existing Password Entropy projects

At the time of writing this, the best known existing library for estimating password strength is zxcvbn by Dropbox (an open-source project on GitHub). It's been adapted to support .netangularjscc#c++gojavajavascriptobjective-cocamlphppythonrestrubyrustscala

Doing it the wrong way

I understand, however, that everyone has different requirements and that sometimes people want to do things the wrong way. For those of you that fit this criterion (or don't have a choice and have presented everything above this section and more to your manager but they refuse to update their methods) at least allow Unicode characters. The moment you limit the password characters to a specific set of characters (i.e. ensuring a lowercase ASCII character exists a-z or specifying characters that the user can or cannot enter !@#$%^&*()), you're just asking for trouble!

P.S. Never trust client-side validation as it can very easily be disabled. That means for those of you trying to validate passwords using javascript STOP. See JavaScript: client-side vs. server-side validation for more information.

The following regular expression pattern does not work in all programming languages, but it does in many of the major programming languages (java.netphpperlruby). Please note that the following regex may not work in your language (or even language version) and you may need to use alternatives (i.e. python: see Python regex matching Unicode properties). Some programming languages even have better methods to check this sort of thing (i.e. using the Password Validation Plugin for mysql) instead of reinventing the wheel. Using node.js the following is valid if using the XRegExp addon or some other conversion tool for Unicode classes as discussed in Javascript + Unicode regexes.

_{If you need to prevent control characters from being entered, you can prompt the user when a regex match occurs using the pattern [^\P{C}\s]. This will ONLY match control characters that are not also whitespace characters - i.e. horizontal tab, line feed, vertical tab.}

The following regex ensures at least one lowercase, uppercase, number, and symbol exist in a 8+ character length password:

^(?=\P{Ll}*\p{Ll})(?=\P{Lu}*\p{Lu})(?=\P{N}*\p{N})(?=[\p{L}\p{N}]*[^\p{L}\p{N}])[\s\S]{8,}$

^ Assert position at the start of the line.
(?=\P{Ll}*\p{Ll}) Ensure at least one lowercase letter (in any script) exists.
(?=\P{Lu}*\p{Lu}) Ensure at least one uppercase letter (in any script) exists.
(?=\P{N}*\p{N}) Ensure at least one number character (in any script) exists.
(?=[\p{L}\p{N}]*[^\p{L}\p{N}]) Ensure at least one of any character (in any script) that isn't a letter or digit exists.
[\s\S]{8,} Matches any character 8 or more times.
$ Assert position at the end of the line.

Please use the above regular expression at your own discretion. You have been warned!

Regexp Java for password validation

Try this:

^(?=.*[0-9])(?=.*[a-z])(?=.*[A-Z])(?=.*[@#$%^&+=])(?=\S+$).{8,}$

Explanation:

^                 # start-of-string
(?=.*[0-9])       # a digit must occur at least once
(?=.*[a-z])       # a lower case letter must occur at least once
(?=.*[A-Z])       # an upper case letter must occur at least once
(?=.*[@#$%^&+=])  # a special character must occur at least once
(?=\S+$)          # no whitespace allowed in the entire string
.{8,}             # anything, at least eight places though
$                 # end-of-string

It's easy to add, modify or remove individual rules, since every rule is an independent "module".

The (?=.*[xyz]) construct eats the entire string (.*) and backtracks to the first occurrence where [xyz] can match. It succeeds if [xyz] is found, it fails otherwise.

The alternative would be using a reluctant qualifier: (?=.*?[xyz]). For a password check, this will hardly make any difference, for much longer strings it could be the more efficient variant.

The most efficient variant (but hardest to read and maintain, therefore the most error-prone) would be (?=[^xyz]*[xyz]), of course. For a regex of this length and for this purpose, I would dis-recommend doing it that way, as it has no real benefits.

python regex for password validation

Here is the Regex for at least one digit, one uppercase letter, at least one lowercase letter, at least one special character

import re
password = input("Enter string to test: ")
# Add any special characters as your wish I used only #@$
if re.match(r"^(?=.*[\d])(?=.*[A-Z])(?=.*[a-z])(?=.*[@#$])[\w\d@#$]{6,12}$", password):
    print ("match")
else:
    print ("Not Match")

Hope this will Help You...