Renamed to securepasswords
This commit is contained in:
@ -0,0 +1,12 @@
|
||||
=== National Institute of Standards and Technology (NIST)
|
||||
|
||||
The National Institute of Standards and Technology (NIST) is a non-regulatory federal agency within the U.S. Department of Commerce.
|
||||
|
||||
Its mission is to promote U.S. innovation and industrial competitiveness by advancing measurement science, standards, and technology in ways that enhance economic security and improve our quality of life.
|
||||
|
||||
NIST develops Federal Information Processing Standards (FIPS), which the Secretary of Commerce approves and federal agencies must comply with.
|
||||
|
||||
NIST also provides guidance documents and recommendations through its Special Publications (SP) 800-series.
|
||||
These guidelines often become the foundation for best practice recommendations across the security industry and are incorporated into other standards.
|
||||
|
||||
(Description from https://www.enzoic.com/surprising-password-guidelines-nist/)
|
@ -0,0 +1,40 @@
|
||||
=== NIST password standard
|
||||
|
||||
The NIST password standard (also known as the https://pages.nist.gov/800-63-3/sp800-63b.html[Special Publications (SP) 800-series]) is a guideline that provides recommendations for implementing secure password systems.
|
||||
|
||||
==== Password rules
|
||||
Here are some of the most important recommendations made by the most recent NIST standard:
|
||||
|
||||
- *no composition rules* +
|
||||
Do not request the user to, e.g., use at least one upper case letter and a special character on their password.
|
||||
Please give them the opportunity to, but do not force them!
|
||||
- *no password hints* +
|
||||
If you wanted people to have a better chance at guessing your password, write it on a note attached to your screen.
|
||||
- *no security questions* +
|
||||
Security questions, also known as knowledge-based authentication (KBA), are outdated.
|
||||
Asking a user, "What's the name of your pet?" or something similar to check if it's him is pretty insecure.
|
||||
- *no unnecessary changing of passwords*
|
||||
If you want users to comply and choose long, hard-to-guess passwords, you should not make them change those passwords unnecessarily after a certain period.
|
||||
- *minimum size of 8 characters* +
|
||||
A secure password nowadays should be at LEAST 8 characters long (up to 64).
|
||||
This is a minimum, not a maximum-minimum!
|
||||
- *support all UNICODE characters* +
|
||||
It would help if you allowed all kinds of UNICODE characters in a password.
|
||||
This also includes emojis and whitespaces.
|
||||
- *check the password against known bad choices*
|
||||
* 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
|
||||
|
||||
==== Usability
|
||||
|
||||
Besides the recommendations above, the NIST standard also recommends increasing the usability of password forms to increase the likelihood of users choosing a strong and secure password. Some of those are:
|
||||
|
||||
- *allow pasting into the password input* +
|
||||
Users should be able to use the "paste" functionality when entering a password.
|
||||
Since this facilitates the use of password managers, it also increases the likelihood that the user will choose a strong password.
|
||||
- *allow displaying the password* +
|
||||
Password inputs should have an option to display the entered password to assist the user in successfully entering a password.
|
||||
- *offer a strength meter* +
|
||||
Add a strength meter on the password creation page to help the user choose a strong and secure password.
|
@ -0,0 +1,19 @@
|
||||
=== Are your passwords secure?
|
||||
|
||||
What about you? Are your passwords secure?
|
||||
|
||||
There are dedicated websites that allow searching if one of your accounts got breached in a past data breach. +
|
||||
Go to https://haveibeenpwned.com/Passwords[Have I Been Pwned] or https://www.dehashed.com/[DEHASHED] per example and test if your account got breached.
|
||||
If so, better change your passwords *right now*!
|
||||
|
||||
==== What can you do to improve the security of your account?
|
||||
- *use different passwords for different accounts* +
|
||||
It is a good thing NOT to use the same password for multiple accounts but rather to use different passwords.
|
||||
* *use passphrases* +
|
||||
Use passphrase generators like https://www.rempe.us/diceware/#eff[Diceware] to generate passphrases.
|
||||
Passphrases are passwords made out of several words instead of randomly generated character sequences.
|
||||
This makes them way easier to remember for us human beings. And by the way: The longer, the better!
|
||||
* *use a password manager* +
|
||||
If you can't remember your different passwords, use a password manager to create and securely store your passwords.
|
||||
- *use two-factor authentication* +
|
||||
If possible, use two-factor authentication methods to add an extra layer of security to your accounts.
|
@ -0,0 +1,32 @@
|
||||
=== Storing passwords
|
||||
|
||||
After a strong and secure password was created, it also has to be stored securely.
|
||||
The NIST gives recommendations on how applications should handle passwords and how to store them securely.
|
||||
|
||||
==== How should a password be stored?
|
||||
|
||||
- first of all: *use encryption and a protected channel for requesting passwords* +
|
||||
The verifier shall use approved encryption and an authenticated protected channel to resist eavesdropping and MitM (Man-in-the-middle) attacks when requesting memorized secrets.
|
||||
- *resistant to offline attacks* +
|
||||
Passwords should be stored in a form that is resistant to offline attacks.
|
||||
- *use salts* +
|
||||
Passwords should be salted before storing them.
|
||||
The salt shall have at least 32 bits in length and should be chosen arbitrarily to minimize salt value collisions among stored hashes.
|
||||
- *use hashing* +
|
||||
Before storing a password, it should be hashed with a one-way key derivation function.
|
||||
The function inputs the password, salt, and cost factor and then generates a password hash. +
|
||||
Examples of suitable key derivation functions:
|
||||
* Password-based Key Derivation Function 2 (https://pages.nist.gov/800-63-3/sp800-63b.html#SP800-132[PBKDF2]) (as large as possible => at least 10.000 iterations)
|
||||
* https://pages.nist.gov/800-63-3/sp800-63b.html#SP800-132[BALLOON]
|
||||
* The key derivation function shall use an approved one-way function such as:
|
||||
** Keyed Hash Message Authentication Code (https://pages.nist.gov/800-63-3/sp800-63b.html#FIPS198-1[HMAC])
|
||||
** any approved hash function in https://pages.nist.gov/800-63-3/sp800-63b.html#SP800-107[SP 800-107]
|
||||
** Secure Hash Algorithm 3 (https://pages.nist.gov/800-63-3/sp800-63b.html#FIPS202[SHA-3])
|
||||
** https://pages.nist.gov/800-63-3/sp800-63b.html#SP800-38B[CMAC]
|
||||
** Keccak Message Authentication Code (KMAC)
|
||||
** Customizable SHAKE (cSHAKE)
|
||||
** https://pages.nist.gov/800-63-3/sp800-63b.html#SP800-185[ParallelHash]
|
||||
- *memory hard key derivation function* +
|
||||
Use memory-hard key derivation functions to increase the needed cost further to perform attacks.
|
||||
- *high cost factor* +
|
||||
The key derivation function's cost factor (iteration count) should be as large as verification server performance will allow. (at least 10.000 iterations)
|
@ -0,0 +1,14 @@
|
||||
=== How long could it take to brute force your password?
|
||||
|
||||
In this assignment, you have to type in a password that is strong enough (at least 4/4).
|
||||
|
||||
After you finish this assignment we highly recommend you try some passwords below to see why they are not good choices:
|
||||
|
||||
* password
|
||||
* johnsmith
|
||||
* 2018/10/4
|
||||
* 1992home
|
||||
* abcabc
|
||||
* fffget
|
||||
* poiuz
|
||||
* @dmin
|
@ -0,0 +1,7 @@
|
||||
In this lesson, the user will learn how to create strong passwords and securely store them.
|
||||
We will take a look at the most important recommendations made by the NIST password standard.
|
||||
|
||||
Goals:
|
||||
|
||||
- The user knows how a strong password should look like and what specifications it should fulfill
|
||||
- The user has a basic overview of what to pay attention to when developing an application that stores passwords
|
@ -0,0 +1,61 @@
|
||||
<!DOCTYPE html>
|
||||
|
||||
<html xmlns:th="http://www.thymeleaf.org">
|
||||
|
||||
<div class="lesson-page-wrapper">
|
||||
<div class="adoc-content" th:replace="doc:lessons/securepasswords/documentation/SecurePasswords_intro.adoc"></div>
|
||||
</div>
|
||||
|
||||
<div class="lesson-page-wrapper">
|
||||
<div class="adoc-content" th:replace="doc:lessons/securepasswords/documentation/SecurePasswords_1.adoc"></div>
|
||||
</div>
|
||||
|
||||
<div class="lesson-page-wrapper">
|
||||
<div class="adoc-content" th:replace="doc:lessons/securepasswords/documentation/SecurePasswords_2.adoc"></div>
|
||||
</div>
|
||||
|
||||
<div class="lesson-page-wrapper">
|
||||
<div class="adoc-content" th:replace="doc:lessons/securepasswords/documentation/SecurePasswords_assignment_introduction.adoc"></div>
|
||||
<div class="attack-container">
|
||||
<div class="assignment-success"><i class="fa fa-2 fa-check hidden" aria-hidden="true"></i></div>
|
||||
<form class="attack-form" accept-charset="UNKNOWN"
|
||||
method="POST" name="form"
|
||||
action="/WebGoat/SecurePasswords/assignment"
|
||||
autocomplete="off">
|
||||
|
||||
<div class="input-group input-group">
|
||||
<input id="myInput" name="password" value="" type="password" class="form-control"
|
||||
placeholder="Enter a secure password..."
|
||||
aria-describedby="password-label">
|
||||
<span class="input-group-addon"><input type="checkbox" onclick="javascript:myFunction()"/> Show password</span>
|
||||
</div>
|
||||
<div class="input-group" style="margin-top: 10px">
|
||||
<button type="submit" class="btn btn-primary">Submit</button>
|
||||
</div>
|
||||
</form>
|
||||
<div class="attack-feedback"></div>
|
||||
<div class="attack-output"></div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="lesson-page-wrapper">
|
||||
<div class="adoc-content" th:replace="doc:lessons/securepasswords/documentation/SecurePasswords_3.adoc"></div>
|
||||
</div>
|
||||
|
||||
<div class="lesson-page-wrapper">
|
||||
<div class="adoc-content" th:replace="doc:lessons/securepasswords/documentation/SecurePasswords_4.adoc"></div>
|
||||
</div>
|
||||
|
||||
<script>
|
||||
function myFunction() {
|
||||
var x = document.getElementById("myInput");
|
||||
if (x.type === "password") {
|
||||
x.type = "text";
|
||||
} else {
|
||||
x.type = "password";
|
||||
}
|
||||
}
|
||||
</script>
|
||||
|
||||
|
||||
</html>
|
@ -0,0 +1,4 @@
|
||||
secure-passwords.title=Secure Passwords
|
||||
securepassword-success=You have succeeded! The password is secure enough.
|
||||
securepassword-failed=You have failed! Try to enter a secure password.
|
||||
show-password=Show Password
|
@ -0,0 +1,4 @@
|
||||
secure-passwords.title=Veilige wachtwoorden
|
||||
securepassword-success=Het is gelukt. Het wachtwoord is sterk genoeg.
|
||||
securepassword-failed=Helaas, probeer een sterker wachtwoord!
|
||||
show-password=Toon wachtwoord
|
@ -0,0 +1,35 @@
|
||||
{
|
||||
"questions": [{
|
||||
"text": "How could an intruder harm the security goal of confidentiality?",
|
||||
"solutions": {
|
||||
"1": "By deleting all the databases.",
|
||||
"2": "By stealing a database where general configuration information for the system is stored.",
|
||||
"3": "By stealing a database where names and emails are stored and uploading it to a website.",
|
||||
"4": "Confidentiality can't be harmed by an intruder."
|
||||
}
|
||||
}, {
|
||||
"text": "How could an intruder harm the security goal of integrity?",
|
||||
"solutions": {
|
||||
"1": "By changing the names and emails of one or more users stored in a database.",
|
||||
"2": "By listening to incoming and outgoing network traffic.",
|
||||
"3": "By bypassing authentication mechanisms that are in place to manage database access.",
|
||||
"4": "Integrity can only be harmed when the intruder has physical access to the database storage."
|
||||
}
|
||||
}, {
|
||||
"text": "How could an intruder harm the security goal of availability?",
|
||||
"solutions": {
|
||||
"1": "By exploiting bugs in the systems software to bypass authentication mechanisms for databases.",
|
||||
"2": "By redirecting emails with sensitive data to other individuals.",
|
||||
"3": "Availability can only be harmed by unplugging the power supply of the storage devices.",
|
||||
"4": "By launching a denial of service attack on the servers."
|
||||
}
|
||||
}, {
|
||||
"text": "What happens if at least one of the CIA security goals is harmed?",
|
||||
"solutions": {
|
||||
"1": "A system can be considered safe until all the goals are harmed. Harming one goal has no effect on the systems security.",
|
||||
"2": "The systems security is compromised even if only one goal is harmed.",
|
||||
"3": "It's not that bad when an attacker reads or changes data, at least some data is still available, hence only when the goal of availability is harmed the security of the system is compromised.",
|
||||
"4": "It shouldn't be a problem if an attacker changes data or makes it unavailable, but reading sensitive data is not tolerable. Theres only a problem when confidentiality is harmed."
|
||||
}
|
||||
}]
|
||||
}
|
Reference in New Issue
Block a user