!!! Overview
[{$pagename}] is a [Best Practices] for dealing with [Password] from an accumulation from many [Years] of experience and a variety sources.

[{$pagename}] is not JUST technical, but also about Business [Best Practices]

!! Do you REALLY need to store [passwords]?  
Number One [Best Practice] is to not do [Password Storage Schemes] at all. Nothing is more efficient than not doing it at all. If you can, use [WebAuthN] or [OpenID Connect] or [User-Managed Access].

!! [Server] Side [{$pagename}]
You __[SHOULD]__ Use [Server-Side Login throttling schemes] to prevent [Brute-Force] [Password] [Attackers]

You __[MUST]__ use [Secure connection] ([HTTPS])

! To [HTTPS] or not to [HTTPS]?[1]
Unless the connection is already secure (that is, tunneled through HTTPS using SSL/TLS), your login form values will be sent in cleartext, which allows anyone eavesdropping on the line between browser and web server will be able to read logins as they pass through. This type of wiretapping is done routinely by governments, but in general we won't address 'owned' wires other than to say this: If you are protecting anything non-trivial, __use [HTTPS]__.

In essence, the only practical way to protect against wiretapping / packet sniffing during login is by using [HTTPS] or another certificate-based [encryption] scheme or a proven & tested challenge-response scheme (for example, the [Diffie-Hellman]-based [SRP]).

%%warning
If you are using [Passwords] are __NOT__ using a [Secure connection], then all else is a waste of time.
%%

! [Server-Side Login throttling schemes]
Use [Server-Side Login throttling schemes] to prevent [Brute-Force] [Password] [Attackers]



! [Web Authentication]
more information on [Web Authentication]

! [NIST.SP.800-63B]
[NIST.SP.800-63B] changes the requirements for memorized secrets (ie [passwords]) in several ways.

! [Password Periodic Changes]
Should an [organizational Entity] mandate regular [Password Periodic Changes]? 

!! Use [Multi-Factor Authentication]
A very effective way to prevent account compromise at the moment is to use [Multi-Factor Authentication]. The most common method for [2FA] at the moment is by using [One-Time passwords] ([OTP]) - special codes you force your users to enter during login. However not every user can or wants to add this extra step, and not every website wants to force users through the [friction] of setting it up and entering codes all the time. 

You [SHOULD] always give them the option. It's never been easier to add [OTP] [2FA] to your login process using third-party [Authenticator Apps]. Both of those also have options for removing the [friction] of typing codes in favor of pressing a button on a smartphone, if your users have smartphones.

Whether you add one-time-password 2FA or not, a layer that [NIST] encourages, which is widely seen as [Best Practice], and which I'd recommend. Rather than an “always on” approach to [MFA], organizations need to use an adaptive, step-up approach based on context. [Risk-Based Authentication] requests leverage contextual information such as [Geolocation], [Internet Protocol Address], device [Fingerprinting] and time of day help determine whether the [user] is really who he claims to be


!! Beware of [Password Anti-Patterns]
[Password Anti-Patterns] are common misconceptions about [passwords] that [SHOULD NOT] be used.

!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [The definitive guide to form-based website authentication|http://stackoverflow.com/questions/549/the-definitive-guide-to-form-based-website-authentication|target='_blank'] - based on information obtained 2016-08-10