Passwords are primarily used as a way of accessing information and also limiting the number of users who can get access to a machine. It is primarily used with a username for the authorization system. Sometimes people use keys instead of passwords due to the increased strength of the keys.
- Stackoverflow.com Wiki
Preventing weak passwords by reading your mind
You see, the world of forgotten passwords is actually a little murky. There are plenty of different perfectly legitimate angles and a bunch of pretty bad ones as well. Chances are you’ve experienced each many times as an end user so let me try and draw on some of these examples to see who’s doing it well, who’s not and what you need to focus on to get it right in your app.
A user’s account on a website is like a house. The password is the key, and logging in is like walking through the front door. When a user can’t remember their password, it’s like losing their keys. When a user’s account is hacked, it’s like their house is getting broken into.
123456, password, rootkit, 111111, 12345678, qwerty, 123456789, 123123, qwertyui, letmein, 12345, 1234, abc123, dvcfghyt, 0, r00tk1t, ìîñêâà, 1234567, 1234567890, 123, fuckyou, 11111111, master, aaaaaa, 1qaz2wsx
Of the many, many, many bad things about passwords, you know what the worst is? Password rules.
In the beginning, things were simple: you had two strings (a username and a password) and if someone knew both of them, they could log in. Easy.
Bill Burr, a manager at the National Institute of Standards and Technology (NIST), wrote a password primer in 2003 that recommended many of the rules we have now: special characters, capitals and numbers. He also added a recommendation that they be updated regularly (THANKS, BILL).
When a user of your application has forgotten their password, it can and should be reset securely.
Security breaches are very common. To make matters worse, when it comes to users’ passwords it is frequent that no reasonable precautions were taken to ensure that they can’t be easily extracted from the breached data.
Authentication is clearly important, but there are many ways to reliably authenticate users – not just passwords. Passwords are written off as inconvenient and unavoidable, but even if true a few years ago, that’s not true today. Due to a combination of sensors, encryption and seasoned technology users, authentication is taking on new (and exciting) forms.
When offering an online service there are two risks to user accounts: Firstly, the service itself can be compromised by an attacker. Secondly, a user’s password could be obtained by an attacker and then be used to target our platform by injecting malicious content or abusing the account.
This is not a “passwords are dead pls don’t use” article, but an attempt at convincing you to consider alternatives to password authentication. It also includes a primer on the different passwordless authentication techniques you might want to use.
The Web Authentication API gives Web applications user-agent-mediated access to authenticators – which are often hardware tokens accessed over USB/BLE/NFC or modules built directly into the platform – for the purposes of generating and challenging application-scoped (eTLD+k) public-key credentials.