I'm installing a new instance of SQL Server Express with mixed mode for access. The password I'm setting is Abcd1234(). According to the docs for strong password guidelines, it's supposed to be valid if it consists of more than 8 of the following:
uppercase letters,
lowercase letters,
numbers, and
non-alphanumeric characters.
My entry satisfies all of the above. Yet, I can't proceed as the validation claims violated rules for strong passwords.
The specified sa password does not meet strong password requirements. For more information about strong password requirements, see "Database Engine Configuration - Account Provisioning" in Setup Help or in SQL Server 2019 Books Online.
What am I missing?
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 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.
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.
The Glassfish JDBC realm features several different properties you can set.
I am interested in the Digest Algorithm and Password Encryption Algorithm properties (that's how they show up in the admin console).
The second one is new as of Glassfish 3.1.2 as near as I can tell.
I have consulted the official Glassfish 3.1.1 documentation but it does not address the new property, and does not really explain what the first property is used for.
There is a documentation bug that references a bug number (13363269) that must point to a defunct bug system because I can't find the bug to which it refers. This phantom bug presumably details what the Password Encryption Algorithm property is for, but alas seems to be lost to the mists of time.
From the command line, the property is named (improbably): digestrealm-password-enc-algorithm. It looks like this will live on next to the digest-algorithm property.
I attempted to read the source code, but the JDBCRealm.java file appears to be missing although I am doubtlessly simply looking in the wrong place. A prior copy that I found does not reference the property anywhere.
What are these two properties for? I have a hazy sense that together they ensure that if I use the realm to login with a plaintext password I can somehow delegate the hashing-and-comparing operations to the realm, provided of course that the hashes used to store the original password and the hashes used on the incoming password were calculated the same way.
The manual also indicates that if I want to use digest authentication that I should be specifying the jdbcDigestRealm JAAS context. If I don't want to use digest authentication, then I should be specifying the jdbcRealm JAAS context. To my eyes, this looks like yet another place where I am effectively specifying what kinds of hashing algorithms are involved.
Thanks in advance for any pointers.
I wrote about this (related issue) here - Glassfish 3.1.2 JDBCRealm configuration.
In short, the password encryption field does not seem to be mandatory at all anymore - so just storing passwords as SHA 256 hashes should work well enough.
For those who are not aware, Lotus Notes is a cool system, which has very powerful database replication abilities, and very strong certificate management and signing.
However that strong certificate usage is itself one of Notes's downfalls.
When you log in to Lotus Notes via a Notes client, the password you use is not stored anywhere, except as the encrypt/decrypt key to the Private Key stored in the Notes ID file on your local workstation.
What this means is that you can have 15 copies of this file, with 15 different passwords, and each one is valid, as long as you have the matching password.
For Identity Management systems, this is pretty crippling, as there is no server side component to access the password change event, rather it is entirely client based, and the server can barely even tell it happened!
The rumours I hear is that in later releases of Lotus Notes/Domino, this ID file based authentication is starting to change.
I am having trouble finding clear cut explanations for what is changing, how, and in what version. (8.5? 9? Later?)
Second part to this question is, what is happening in terms of Active Directory integration? I heard it rumoured that AD authentication might be allowed instead of ID file authentication. My guess on that aspect is that the ID file stored on the server will still be used for authorization, but the successful Active Directory authentication will be used to unlock access to it? Or is it some other model?
Looking for someones perspective who has figured this out already!
On a side note, there is a second password (httpPassword) that is used when Notes's Webmail is accessed, since of course the server has no access to the local ID file when the user authenticates. One assumes this is the model they would move to for other forms of authentication, but as we all know, assuming is a bad plan!
Notes Domino 8.5 has the new ID Vault feature. It was released in early January.
ID Vault works by keeping a copy of the id securely on the server. It then provisions the id on demand to the user. This allows for a configuration where the user asks the server to reset the password and the server makes the change to the id file before downloading it the the user.
More info on ID Vault here:
A New Way to Manage Notes User IDs and Passwords (dominoblog.com)
Sneak peak - the Domino 8.5 id vault (pmooney.net)
Updated: 8.5 has been released.