Two big concerns on the actual password security side:
You're enforcing hard-to-remember-but-easy-to-crack passwords. (Obligatory XKCD: Correct Horse Battery Staple)
Rather, the current guidance from the National Institute of Science and Technology, the standards body responsible for people writing commercial software in the United States is:
5.1.1.1 Memorized Secret Authenticators
Memorized secrets SHALL be at least 8 characters in length if chosen by the subscriber. Memorized secrets chosen randomly by the CSP or verifier SHALL be at least 6 characters in length and MAY be entirely numeric. If the CSP or verifier disallows a chosen memorized secret based on its appearance on a blacklist of compromised values, the subscriber SHALL be required to choose a different memorized secret. No other complexity requirements for memorized secrets SHOULD be imposed. A rationale for this is presented in Appendix A Strength of Memorized Secrets.
You have the 8 character minimum limit right, but rather than making sure users supply lower case, capitals, numbers, and non-alphanumeric symbols, you should be making a call to a service that has a list of known insecure passwords. I use the Pwnd Passwords API call to the database made available by Troy Hunt. If you want to be truly paranoid, download the hash files and import them into a database yourself so that you can check them while knowing that no information about their password is leaving your server.
Which brings me to the second big concern:
Never show the user their password (unless they explicitly ask for it while they're typing/pasting it in).
Even on your own test system that you're setting up in a server at your own home that will never serve traffic to real customers.
After all, if you're the only one who will touch it, you can always reset the password. And if there are customers on the server, you don't know if they're in a coffee shop and there's a malicious person standing over their shoulder. There's a reason why every password bar only shows dots instead of the plaintext password. Respect that and respect your users' privacy.
And besides, if the user ever does forget their password, you should be using a password reset system, not implying that they should have recorded it somewhere. (And when building the password reset system, follow the guidelines laid out by OWASP.
Remember, it's not your password, it's theirs... and they're likely reusing that password for their banking site and the rest of their online presence. You don't want to be responsible for that information, so don't ever let anyone, including them, be able to access it in plaintext after they have sent it to your server.
Two big concerns on the actual password security side:
You're enforcing hard-to-remember-but-easy-to-crack passwords. (Obligatory XKCD: Correct Horse Battery Staple)
Rather, the current guidance from the National Institute of Science and Technology, the standards body responsible for people writing commercial software in the United States is:
5.1.1.1 Memorized Secret Authenticators
Memorized secrets SHALL be at least 8 characters in length if chosen by the subscriber. Memorized secrets chosen randomly by the CSP or verifier SHALL be at least 6 characters in length and MAY be entirely numeric. If the CSP or verifier disallows a chosen memorized secret based on its appearance on a blacklist of compromised values, the subscriber SHALL be required to choose a different memorized secret. No other complexity requirements for memorized secrets SHOULD be imposed. A rationale for this is presented in Appendix A Strength of Memorized Secrets.
You have the 8 character minimum limit right, but rather than making sure users supply lower case, capitals, numbers, and non-alphanumeric symbols, you should be making a call to a service that has a list of known insecure passwords. I use the Pwnd Passwords API call to the database made available by Troy Hunt. If you want to be truly paranoid, download the hash files and import them into a database yourself so that you can check them while knowing that no information about their password is leaving your server.
Which brings me to the second big concern:
Never show the user their password (unless they explicitly ask for it while they're typing/pasting it in).
Even on your own test system that you're setting up in a server at your own home that will never serve traffic to real customers.
After all, if you're the only one who will touch it, you can always reset the password. And if there are customers on the server, you don't know if they're in a coffee shop and there's a malicious person standing over their shoulder. There's a reason why every password bar only shows dots instead of the plaintext password. Respect that and respect your users' privacy.
And besides, if the user ever does forget their password, you should be using a password reset system, not implying that they should have recorded it somewhere. (And when building the password reset system, follow the guidelines laid out by OWASP.
Remember, it's not your password, it's theirs... and they're likely reusing that password for their banking site and the rest of their online presence. You don't want to be responsible for that information, so don't ever let anyone, including them, be able to access it in plaintext after they have sent it to your server.
Two big concerns on the actual password security side:
You're enforcing hard-to-remember-but-easy-to-crack passwords. (Obligatory XKCD: Correct Horse Battery Staple)
Rather, the current guidance from the National Institute of Science and Technology, the standards body responsible for people writing commercial software in the United States is:
5.1.1.1 Memorized Secret Authenticators
Memorized secrets SHALL be at least 8 characters in length if chosen by the subscriber. Memorized secrets chosen randomly by the CSP or verifier SHALL be at least 6 characters in length and MAY be entirely numeric. If the CSP or verifier disallows a chosen memorized secret based on its appearance on a blacklist of compromised values, the subscriber SHALL be required to choose a different memorized secret. No other complexity requirements for memorized secrets SHOULD be imposed. A rationale for this is presented in Appendix A Strength of Memorized Secrets.
You have the 8 character minimum limit right, but rather than making sure users supply lower case, capitals, numbers, and non-alphanumeric symbols, you should be making a call to a service that has a list of known insecure passwords. I use the Pwnd Passwords API call to the database made available by Troy Hunt. If you want to be truly paranoid, download the hash files and import them into a database yourself so that you can check them while knowing that no information about their password is leaving your server.
Which brings me to the second big concern:
Never show the user their password (unless they explicitly ask for it while they're typing/pasting it in).
Even on your own test system that you're setting up in a server at your own home that will never serve traffic to real customers.
After all, if you're the only one who will touch it, you can always reset the password. And if there are customers on the server, you don't know if they're in a coffee shop and there's a malicious person standing over their shoulder. There's a reason why every password bar only shows dots instead of the plaintext password. Respect that and respect your users' privacy.
And besides, if the user ever does forget their password, you should be using a password reset system, not implying that they should have recorded it somewhere. (And when building the password reset system, follow the guidelines laid out by OWASP.
Remember, it's not your password, it's theirs... and they're likely reusing that password for their banking site and the rest of their online presence. You don't want to be responsible for that information, so don't ever let anyone, including them, be able to access it in plaintext after they have sent it to your server.
Two big concerns on the actual password security side:
You're enforcing hard-to-remember-but-easy-to-crack passwords. (Obligatory XKCD: Correct Horse Battery Staple)
Rather, the current guidance from the National Institute of Science and Technology, the standards body responsible for people writing commercial software in the United States is:
5.1.1.1 Memorized Secret Authenticators
Memorized secrets SHALL be at least 8 characters in length if chosen by the subscriber. Memorized secrets chosen randomly by the CSP or verifier SHALL be at least 6 characters in length and MAY be entirely numeric. If the CSP or verifier disallows a chosen memorized secret based on its appearance on a blacklist of compromised values, the subscriber SHALL be required to choose a different memorized secret. No other complexity requirements for memorized secrets SHOULD be imposed. A rationale for this is presented in Appendix A Strength of Memorized Secrets.
You have the 8 character minimum limit right, but rather than making sure users supply lower case, capitals, numbers, and non-alphanumeric symbols, you should be making a call to a service that has a list of known insecure passwords. I use the Pwnd Passwords API call to the database made available by Troy Hunt. If you want to be truly paranoid, download the hash files and import them into a database yourself so that you can check them while knowing that no information about their password is leaving your server.
Which brings me to the second big concern:
Never show the user their password. (unless they explicitly ask for it while they're typing/pasting it in).
Even on your own test system that you're setting up in a server at your own home that will never serve traffic to real customers.
After all, if you're the only one who will touch it, you can always reset the password. And if there are customers on the server, you don't know if they're in a coffee shop and there's a malicious person standing over their shoulder. There's a reason why every password bar only shows dots instead of the plaintext password. Respect that and respect your users' privacy.
And besides, if the user ever does forget their password, you should be using a password reset system, not implying that they should have recorded it somewhere. (And when building the password reset system, follow the guidelines laid out by OWASP.
Remember, it's not your password, it's theirs... and they're likely reusing that password for their banking site and the rest of their online presence. You don't want to be responsible for that information, so don't ever let anyone, including them, be able to access it in plaintext after they have sent it to your server.
Two big concerns on the actual password security side:
You're enforcing hard-to-remember-but-easy-to-crack passwords. (Obligatory XKCD: Correct Horse Battery Staple)
Rather, the current guidance from the National Institute of Science and Technology, the standards body responsible for people writing commercial software in the United States is:
5.1.1.1 Memorized Secret Authenticators
Memorized secrets SHALL be at least 8 characters in length if chosen by the subscriber. Memorized secrets chosen randomly by the CSP or verifier SHALL be at least 6 characters in length and MAY be entirely numeric. If the CSP or verifier disallows a chosen memorized secret based on its appearance on a blacklist of compromised values, the subscriber SHALL be required to choose a different memorized secret. No other complexity requirements for memorized secrets SHOULD be imposed. A rationale for this is presented in Appendix A Strength of Memorized Secrets.
You have the 8 character minimum limit right, but rather than making sure users supply lower case, capitals, numbers, and non-alphanumeric symbols, you should be making a call to a service that has a list of known insecure passwords. I use the Pwnd Passwords API call to the database made available by Troy Hunt. If you want to be truly paranoid, download the hash files and import them into a database yourself so that you can check them while knowing that no information about their password is leaving your server.
Which brings me to the second big concern:
Never show the user their password.
Even on your own test system that you're setting up in a server at your own home that will never serve traffic to real customers.
After all, if you're the only one who will touch it, you can always reset the password. And if there are customers on the server, you don't know if they're in a coffee shop and there's a malicious person standing over their shoulder. There's a reason why every password bar only shows dots instead of the plaintext password. Respect that and respect your users' privacy.
And besides, if the user ever does forget their password, you should be using a password reset system, not implying that they should have recorded it somewhere. (And when building the password reset system, follow the guidelines laid out by OWASP.
Remember, it's not your password, it's theirs... and they're likely reusing that password for their banking site and the rest of their online presence. You don't want to be responsible for that information, so don't ever let anyone, including them, be able to access it in plaintext.
Two big concerns on the actual password security side:
You're enforcing hard-to-remember-but-easy-to-crack passwords. (Obligatory XKCD: Correct Horse Battery Staple)
Rather, the current guidance from the National Institute of Science and Technology, the standards body responsible for people writing commercial software in the United States is:
5.1.1.1 Memorized Secret Authenticators
Memorized secrets SHALL be at least 8 characters in length if chosen by the subscriber. Memorized secrets chosen randomly by the CSP or verifier SHALL be at least 6 characters in length and MAY be entirely numeric. If the CSP or verifier disallows a chosen memorized secret based on its appearance on a blacklist of compromised values, the subscriber SHALL be required to choose a different memorized secret. No other complexity requirements for memorized secrets SHOULD be imposed. A rationale for this is presented in Appendix A Strength of Memorized Secrets.
You have the 8 character minimum limit right, but rather than making sure users supply lower case, capitals, numbers, and non-alphanumeric symbols, you should be making a call to a service that has a list of known insecure passwords. I use the Pwnd Passwords API call to the database made available by Troy Hunt. If you want to be truly paranoid, download the hash files and import them into a database yourself so that you can check them while knowing that no information about their password is leaving your server.
Which brings me to the second big concern:
Never show the user their password (unless they explicitly ask for it while they're typing/pasting it in).
Even on your own test system that you're setting up in a server at your own home that will never serve traffic to real customers.
After all, if you're the only one who will touch it, you can always reset the password. And if there are customers on the server, you don't know if they're in a coffee shop and there's a malicious person standing over their shoulder. There's a reason why every password bar only shows dots instead of the plaintext password. Respect that and respect your users' privacy.
And besides, if the user ever does forget their password, you should be using a password reset system, not implying that they should have recorded it somewhere. (And when building the password reset system, follow the guidelines laid out by OWASP.
Remember, it's not your password, it's theirs... and they're likely reusing that password for their banking site and the rest of their online presence. You don't want to be responsible for that information, so don't ever let anyone, including them, be able to access it in plaintext after they have sent it to your server.
Two big concerns on the actual password security side:
You're enforcing hard-to-remember-but-easy-to-crack passwords. (Obligatory XKCD: Correct Horse Battery Staple)
Rather, the current guidance from the National Institute of Science and Technology, the standards body responsible for people writing commercial software in the United States is:
5.1.1.1 Memorized Secret Authenticators
Memorized secrets SHALL be at least 8 characters in length if chosen by the subscriber. Memorized secrets chosen randomly by the CSP or verifier SHALL be at least 6 characters in length and MAY be entirely numeric. If the CSP or verifier disallows a chosen memorized secret based on its appearance on a blacklist of compromised values, the subscriber SHALL be required to choose a different memorized secret. No other complexity requirements for memorized secrets SHOULD be imposed. A rationale for this is presented in Appendix A Strength of Memorized Secrets.
You have the 8 character minimum limit right, but rather than making sure users supply lower case, capitals, numbers, and non-alphanumeric symbols, you should be making a call to a service that has a list of known insecure passwords. I use the Pwnd Passwords API call to the database made available by Troy Hunt. If you want to be truly paranoid, download the hash files and import them into a database yourself so that you can check them while knowing that no information about their password is leaving your server.
Which brings me to the second big concern:
Never show the user their password.
Even on your own test system that you're setting up in a server at your own home that will never serve traffic to real customers.
After all, if you're the only one who will touch it, you can always reset the password. And if there are customers on the server, you don't know if they're in a coffee shop and there's a malicious person standing over their shoulder. There's a reason why every password bar only shows dots instead of the plaintext password. Respect that and respect your users' privacy.
And besides, if the user ever does forget their password, you should be using a password reset system, not implying that they should have recorded it somewhere. (And when building the password reset system, follow the guidelines laid out by OWASP.
Remember, it's not your password, it's theirs... and they're likely reusing that password for their banking site and the rest of their online presence. You don't want to be responsible for that information, so don't ever let anyone, including them, be able to access it in plaintext.