Authentication

What happend if a user use products where with a domain used to redirect him, could be owned after some time by a third party: Bugtraq: Logic security flaw in TP-LINK - tplinklogin.net

JSON Web Tokens

Aka JWT

Shouldn't be used for session (can't be invalidated before the expiration date) and shouldn't contains sensitive data, just userid, roles, etc. unless you use JSON Web Encryption (JWE)

[...] defines a compact and self-contained way for securely transmitting information between parties as a JSON object [...] Compact and self-contained: all data needed for authentication exists in the token. It can be transmitted quickly because of its small size.

Digitally signed: tokens are verified against a secret key on the server. They are secure because the content of the JWT can’t be tampered with unless the secret key is known.

Simple: JWTs are conceptually straight-forward and have low overhead. Since they provide a stateless means for authentication, they can be used across multiple servers and domains without running into CORS issues.

Login with email

If you are storing email addresses then you probably should store them in their original case (the recipient at least) to be safe. However, always compare them case-insensitively in order to avoid duplicates. – I it ok to use uppercase letter in email address? - Webmaster Stack Exchange

The local mailbox part (the username), however, is case sensitive. The email address ReCipiENt@eXaMPle.cOm is indeed different from recipient@example.com (but it the same as ReCipiENt@example.com).

Simply put: Only the username itself is case sensitive. Email addresses are not affected by the case. — Are email addresse case sensitive? - Quora

The local-part of a mailbox MUST BE treated as case sensitive. Therefore, SMTP implementations MUST take care to preserve the case of mailbox local-parts. Mailbox domains are not case sensitive. In particular, for some hosts the user "smith" is different from the user "Smith". However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged. — https://www.rfc-editor.org/rfc/rfc2821.txt

“Invalid Username or Password”, a useless security measure

You can confirm if an username exist by trying to create an new account with the same username.

https://kev.inburke.com/kevin/invalid-username-or-password-useless/

  • Rate limiting can go a fair way to preventing brute force attacks. To find email addresses, an attacker is going to need to try a lot of email addresses and/or a lot of passwords, and get a lot of them wrong. Consider throttling invalid login attempts by IP address or subnet. Check submitted passwords against a dictionary of common passwords (123456, monkey, etc) and ban that traffic extra hard. Exponential backoff (forcing attackers to try again after 1, 2, 4, 8, 16.. seconds) is useful.

  • Give guidance to users about creating strong passwords. Allow easy integration with LastPass or 1Password.

  • Add a 2-factor auth option to your website. Encourage users to use it.

  • Warn users about malicious behavior ("someone is trying to snoop your password") and contact them about suspicious logins.

Graphical password

Password

Be carefull with renew password links send by email. See Password-less login problems.

Use a password manager:

More informations about password managers:

Password reuse

You don’t use the same brush everywhere, so why do you reuse the same password? — Robert Malmgren on Twitter: "Awesome, and very graphical, Norwegian info card about password security - ”You don’t use the same brush everywhere, so why do you reuse the same password?”. An excellent question!… https://t.co/WDSJHlJ7Jw"

Password rules

User (advices):

  • use long password

  • use mix of special chars, numbers, higher case and lowercase

Implementation:

Password strength:

See lists of commonly used passwords

Password leaks

Database, clear text saved in shared files, etc.

SSO

Aka Single sign-on.

If credentials leak, this could give access to more than one application/website.

Note: If for any reason (a good or not) the SSO provider could disable/delete the account. Some implementation don't provide a way to use an other method to sign-in, that means the user will be locked out. Never Use Google to Sign-In | Gurjeet Singh

Examples: OAuth, Google, Facebook, Twitter, LinkedIn, Github, etc.

Password hash cracking

Fcrack zip

-l (#-#): specify the minimum and maximum length of passwords to check
-b : use brute force to crack the password
-c (charset): specify the character set to use
-u : unzip / filter incorrect passwords

John the ripper

zip2john /path/to/file.zip > zip_hash.txt
john –wordlist=/path/to/wordlist.txt zip_hash.txt

Password-less login

Use an access token or a public-private key (ex: SSH key)

provide only your email address and a link is sent to that email address. You click the link, which contains a special login code, and the website logs you in and deactivates the code so it can no longer be used. Subsequent visits to that URL just give a 403. In other words, every login is treated like a password reset. For many use cases, this could be a real pain, but for the case of, say, a site where a handful of internal users need access to an admin panel, it’s really nice to not have to deal with one more password. — http://jon.smajda.com/2014/10/20/mailbox-and-facebook-app-links/

But use POST not GET! 15min lifetime, 1 usage, only sent by a user request (from the app/website)

Problems:

TOTP

Should not used to authentificate users, but only validate the auth request (2 factor auth) because secret key can be stolen on the client or the server side.

Can be use to open a port for SSH login: https://github.com/benjojo/totp-ssh-fluxer

Client certificate

Authenticate clients with certificates

Biometrics

Face, fingerprint, iris/retina and DNA

Never use biometrics as authentification, because we can't change it if it's compromised (biometric thieft). And also because not everyone own it (inherited gene mutation / defect) or it could be lost / altered after an accident, a disease, etc.

Biometrics are a username, not a password.

— https://twitter.com/netik/status/924333873252646914

It is plain stupid to use something that you can't change and that you leave everywhere every day as a security token

— Frank Rieger from Chaos Computer Club: CCC | Chaos Computer Club breaks Apple TouchID

Issues:

  • the device not recognizing the fingerprint for example when the finger has been injured

  • the checksum can be leaked (user’s identity steal) (especially for centralized database). SHOULD use Zero-Knowledge Proof

  • can be fool by using the fingerprint:

    • use a scotch tape to copy the previous used fingerprint then past it on the reader with your finger

    • print in 3d or using conductive ink a fingerprint

    • any other solution mimic finger with fingerprint

  • face recognition: use a picture (ex: a selfie) or a video

See also Face

Two-factor authentication

Aka 2FA

My Twitter account, two email addresses, & my phone. It was not due to passwords, they hacked my phone account itself. Someone called @verizon impersonating me and successfully changed my SIM & unsuccessfully attempted to change my phone number. By calling @verizon and successfully changing my phone's SIM, the hacker bypassed two-factor verification which I have on all accounts. The hacker got access by changing my SIM which redirected texts, then resetting my passwords to trigger two-factor authentication. — https://twitter.com/deray/status/741356147479842816

Software keys

Each version has private key to decode unique certificat from software version + user name encoded with public key (specific for a version of the software)

Usurpation & social engineering

PreviousSecurityNextSecurity

Last updated