We have achieved internationalization in the application, but now we want to have support for user can enter password in his own language(Arabic, Russian, Chinese) etc. Here the problem is validation gets fail for upper case and lower case characters. So, please help me provide standard validations rules or password policy which can be applied to authenticate user from any language.
I've looked at this many years ago, and I've been told that most of the users are using Password that are ascii characters, because it's not possible to compose complex characters (Kanji) without displaying them on the screen.
Also the new recommendations from NIST is to stop trying to impose specific characters, but just enforce a minimal length of at least 8 characters, and check against a dictionary of known compromised passwords.
Related
I want to have a password policy that is supported by most of the password managers and generators like LastPass and chrome's password generator.
Keep registration and login as simple as possible, follow web accessibility guidelines, and don't have a password policy.
Bruce Schneider summed up the latest NIST password best practices.
Don't have password rules, they'll just interfere with generated passwords.
NIST: "Do not impose other composition rules (e.g. mixtures of
different character types) on memorized secrets."
NIST: "Encourage users to make memorized secrets as lengthy as they want, using any characters they like (including spaces), thus aiding memorization."
NIST: "Allow at least 64 characters in length to support the use of passphrases."
Don't expire passwords.
NIST: "Do not require that memorized secrets be changed arbitrarily
(e.g., periodically) unless there is a user request or evidence of
authenticator compromise."
Make sure you're compatible with a password manager.
That last one means don't do anything special with registration and login. Basically follow guidelines for web accessibility.
Use an HTML form with standard inputs
Use <label>
Use text or email type for username input
Use password type for the password
Use obvious names for your inputs
NIST: "Support copy and paste functionality in fields for entering memorized secrets, including passphrases."
Don't dynamically alter the form
Don't change the names and ids
Make sure the form renders on page load
And test your registration and login with a few popular password mangers. Don't forget mobile!
See also
1Password's recommendations
Making password managers play ball with your login form
Web Accessibility For Developers
NIST Special Publication 800-63B Digital Identity Guidelines Authentication and Lifecycle Management Section 10.2.1 "Memorized Secrets"
We are writing new applications and in requirements there are some rules about passwords:
cannot contain 6 repeated pharses in a
row
cannot be the same as last 6 passwords
Second point is easy because we have hashes of this passwords but how can we check 6 repeated pharses?
Example:
first password: kotek123
second password: kot453
how can I check subsequence if I just have hash of this passwords? Is it even possible?
How work masked passwords, I mean when password is kotek123 then some banks just want k#t##23 to log in? Do they store hashes of all possibilities?
perhaps, you should store all subsequences and check if any of them have occured in the previous six passwords.
So it's possible, but very uncomfortable for clients and for developers as well . I wouldn't like to use such a system.
Recently we had the same problem in our system, but we didn't want to poison our lives, so we check similarity of last and new password. It looks simple to do, because, usually, when user wants to change the password, he have to give both passwords, last and new.
I'm curious what method you will apply
I don't think this is possible, if you only have the hash value. This is exactly the goal of hashing a password.
By the way, in the example, the passwords are very different. I recomend just using long passwords, with special characters, and check that on the password creation.
I think masked passwords just store some characters in the database
I am trying to do user authentication using Apacheds Server. For that I am using Password Policy defined. Most of the authentication requirements are met using these policies, but one thing I am not able to do is password pattern. Is there a way to check if user password meets with particular pattern requirements. Requirements I need are:
Uppercase character
Lowercase character
number
special character
You need to provide a custom PasswordValidator to achieve this. See DefaultPasswordValidator if you need an implementation sample.
Use Case
I'm building an iPhone app with a simple signup and login.
When a user signs up/logs in, I want the Ruby (Sinatra) server to generate/fetch and return an access token for that user that the iPhone client can then send with every subsequent request using Basic Authentication over HTTPS.
I'm not yet implementing OAuth 2.0 so that third party apps can access the server. Right now, I'm just building a simple, internal API (for my own, first-party, iPhone app).
Example
Basically, I want to generate a secret API key like Stripe's: https://manage.stripe.com/account/apikeys
For example: sk_test_NMss5Xyp42TnLD9tW9vANWMr
What's the best way to do that, say in Ruby?
The Ruby stdlib provides an entire class of secure random data generators called SecureRandom. Whatever you want, you can probably find it there.
Stripe's keys are essentially URL-safe Base64. You can get something very similar like so:
require 'securerandom'
p "sk_test_" + SecureRandom.urlsafe_base64
(Stripe does strip out non-alphanumeric characters, but that's trivial to do with gsub if you don't want hyphens in your keys.)
I recently published a gem called sssecrets (for Simple Structured Secrets) to solve this problem.
Sssecrets is a reusable implementation of GitHub's API token format (which is also used by NPM), and it's designed to make it simple for developers to issue secure secret tokens that are easy to detect when leaked.
Simple Structured Secrets provides a compact format with properties that are optimized for detection with static analysis tools. That makes it possible to automatically detect when secrets are leaked in a codebase using features like GitHub Secret Scanning or GitLab Secret Detection.
Why Use Structured Secrets?
Using a structured format for secrets is really important for security reasons. If you're a developer and your application issues some kind of access tokens (API keys, PATs, etc), you should try to format these in a way that both identifies the string as a secret token and provides insight into its permissions. For bonus points, you should also provide example (dummy) tokens and regexes for them in your documentation.
Here's an example of a bad secret. As of the time of writing, HashiCorp Vault's API access tokens look like this (ref):
f3b09679-3001-009d-2b80-9c306ab81aa6
You might think that this is pretty is a pretty easy pattern to search for, but here's the issue: It's just a UUID string.
While random, strings in this format are used in many places for non-sensitive purposes. Meaning that, given a random UUID formatted string, it's impossible to know whether it's a sensitive API credential or a garden-variety identifier for something mundane. In cases like these, secret scanning can't help much.
What's in a Structured Secret?
Structured secrets have three parts:
A prefix (2-10 characters, defined by you)
30 characters of randomness
A 6 character checksum
That's it!
Here's the format:
[prefix]_[randomness][checksum]
An example Sssecret, with an org of t and a type of k, looks like this:
tk_GNrRoBa1p9nuwm7XrWkrhYUNQ7edOw4GUp8I
Prefix
Token prefixes are a simple and effective method to make tokens identifiable. Slack, Stripe, GitHub, and others have adopted this approach to great effect.
Sssecrets allows you to provide two abbreviated strings, org and type, which together make up the token prefix. Generally, org would be used to specify an overarching identifier (like your company or app), while type is intended to identify the token type (i.e., OAuth tokens, refresh tokens, etc) in some way. To maintain a compact and consistent format for Sssecret tokens, org and type together should not exceed 10 characters in length.
Entropy
Simple Structured Secret tokens have an entropy of 178:
Math.log(((“a”..“z”).to_a + (“A”..“Z”).to_a + (0..9).to_a).length)/Math.log(2) * 30 = 178
See the GitHub blog.
Checksum
The random component of the token is used to calculate a CRC32 checksum. This checksum is encoded in Base62 and padded with leading zeroes to ensure it's always 6 characters in length.
The token checksum can be used as a first-pass validity check. Using these checksums, false positives can be more or less eliminated when a codebase is being scanned for secrets, as fake tokens can be ignored without the need to query a backend or database.
Note that this library can only check whether a given token is in the correct form and has a valid checksum. To fully determine whether a given token is active, you'll still need to implement your own logic for checking the validity of tokens you've issued.
Another note: Because Sssecrets uses the same format as GitHub tokens, you can also perform offline validation of GitHub-issued secrets with SimpleStructuredSecrets#validate.
Further Reading
You can learn more about GitHub's design process and the properties of this API token format on the GitHub blog.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Should users be able to enter a password such as " 12345" or "12345 " – a space at the beginning or end? Or would you trim the password to remove the leading or trailing spaces because it may just a typing error.
Yes, they should.
It annoys me to no end when people decide how my password should behave especially when it's nonsensical. I would like more than 8 characters please.
You should be hashing the password, so maximum character lengths and spaces at the end don't matter.
No, you should not trim it.
You require a user to enter the password twice (when creating it) to eliminate typing errors. Therefore a space doesn't matter.
Let me tell you a story.
I needed to create an account on an ecommerce site, so I ran my random password generator to make an 8 character upper/lower/number/punctuation password, pasted it in twice to confirm it, finished registering with all of my personal information, and saved the random password in a local PGP-encrypted file for later use.
Later on I tried logging in, but pasting the password again didn't work. After a bit of testing, I was horrified to find that the site had stripped out all punctuation marks from the original password, in some misguided attempt at sanitization, reducing my password to three easily brute forceable letters.
DON'T trim or sanitize users' passwords.
Never "clean up" a password simply to account for "typing mistakes". This will confuse users and in some cases make it impossible for them to login. In fact, don't ever change a password behind a user's back...always warn them that a password is invalid and let them try a new one.
A good example that I recently ran into was with a 3Com switch. The web interface allowed me to change the admin password, but didn't warn me that the password was limited to eight characters. I entered a password that was longer than eight characters. When I tried to login after the change, it simply rejected my password. If I only used the first eight characters, however, I was able to login (trial and error on my part, not fun).
Passwords these days don't look the way they used to. For instance, my passwords often look like this:
Man, this program is really ticking me off!
You should validate the password with a confirmation field anyway. If they make the typo twice - then you hopefully have a forgot password or a reset feature in place.
The space shouldn't matter as you shouldn't be storing it in plain text.
The moment you make such a decision is the moment you start walking down the path of micro-management (over your users in this case).
Does a password containing a space break your system? Or is it a security risk? Then don't worry. Let your users deal with their own errors, even if that means they have to get frustrated. Their typo should never be your problem.
Space is a regular password character, and you shouldn't remove it.
Since you probably hash the password before storing it in the database, the space will be treated as any other character.
I'm voting for: No, they shouldn't:
There's a big benefit for not allowing users to use spaces at the beginning and end of passwords and that's simply that it eliminates the problem which often arises when a user copies and pastes their password (e.g. from an email) and it includes white space which isn't part of the password.
The user then gets frustrated, thinks the system is broken and contacts support. A developer is promptly pulled onto the project to check the "buggy" login process only to spend a day pulling out his/her hair until he/she realises the problem.
I think enforcing this policy when creating a password solves more problems than it creates.
It is fine for the password to contain it as already mentioned however I would add that when generating new random passwords (say for a sensible reset lost password system) you should avoid generating ones containing such tricky characters.
If the password is sufficiently long and random then this will make up for the restriction of a few tricky characters will make the end user's life considerably easier...
I've been to a conference more than once where someone logged in to their account for a demo after the computer display was already up on the big screen, didn't change focus to the password field correctly, and thus their password was revealed to the entire audience.
Anyone who might have to enter credentials in front of others should consider keeping a trailing space or three in their password, just in case. And when building authentication systems, you should never trim those spaces.
Since it's bad juju to store the password as text, there's no need to trim() the password since it'll immediately be hashed.
...
on a similar note, am I correct in believing that passwords shouldn't need to be regex validated to for sql injection since they'll be hashed and not inserted as plain text in the database?
I don't care. So long as whatever you do to the password when it is being set is also done to it when being entered later on. Trim, truncate, change case, salt, hash, whatever - just do it consistently.
Presumably you aren't storing the actual password anyway, so...