5 ms·

I wrote a Rails plugin for magic links at https://github.com/rocketshipio/nopassword https://github.com/rocketshipio/nopassword that doesn’t suffer from many of

I wrote a Rails plugin for magic links at https://github.com/rocketshipio/nopassword https://github.com/rocketshipio/nopassword that doesn’t suffer from many of the problems I’m seeing in the comments. The big thing is I only use a 6 digit numerical code that people have to copy and paste or type into the browser which they’re authenticating. I looked at stuffing a token into a URL, but it’s not a good idea because the email client may try opening the link to preview it or it may try opening the link in the wrong app/browser, such as an in-app browser. That may sound super insecure, but the 6 digit code is half the secret that’s needed to authenticate. The browser that the person is using to login has a much longer complex secret that must be included with the code. Additionally, this combination must be authenticated within a set number of attempts, 3 by default, within a certain timeframe, 5 minutes by default. My motivations for creating this, instead of using something like devise with passwords, is because I have seen soooooo many non-technical people get tripped up by passwords. I know there’s sign-in with Google, MS, etc. via OAuth, but I wanted to give people a way to login to web applications without being under the watchful eye of big tech. I’m currently using it in production for all of my Rails apps, like https://legiblenews.com/email_authentication/new https://legiblenews.com/email_authentication/new A better description of why and how it works at https://github.com/rocketshipio/nopassword https://github.com/rocketshipio/nopassword

deleted 4y ago
[deleted]
aaaaaaaaaaab 4y ago
So if I have 700k usernames I can pwn one of them with 50% probability. Cool! With 3 attempts allowed I only need 230k usernames, even better! The "secret" stored in the browser doesn't protect you from this, since I'm not stealing someone's code; I'm logging in from my own browser. (Of course I'm doing this via a botnet, so you won't notice it by IP address)
- Isinlor 4y ago
  With passwords you will get even higher probability if you just try 100 most popular passwords allowed by the service on hundreds of thousands of users. Try making password creation too difficult and now password reset will be the default authentication for a lot of users anyway.
  - aaaaaaaaaaab 4y ago
    The 100 most popular passwords should already be blacklisted during registration, so it wouldn't be possible to set them as your password. I have nothing against password-reset-as-authentication aka "magic links", when done properly. And by properly I mean not using an ultra-low entropy auth code, like the parent is proposing (6 decimal digits, aka 20 bits of entropy).
- joshstrange 4y ago
  I'm pretty sure you are missing how they implementing this. It sounds like at time of the request to send the code the browser either generates and sends to the server (or gets from the server) a longer/more-complicated secret. Both that secret (which is probably account-specific, the one you requested login to) and the 6 digit code are required. You can't just guess the code, the code has to be combined with another account-specific token. By regenerating longer token each time a 6-digit token is required and only allowing something like 3 guesses per longer token (Before regenerating and sending a new 6-digit code) you have a secure system.
  - aaaaaaaaaaab 4y ago
    No, actually I'm pretty sure you are missing why their system is insecure. But sure, let me explain it: Step 1: acquire a list of 230 000 usernames/emails. Step 2: for each username/email, launch a browser and request a login code. The login code is sent to the users' email address, and the super-ultra-secret token is stored in the browser. Step 3: for each username/email, do 3 random guesses from their respective browsers. Each guess is a Bernoulli trial with P = 10^-6. Thus the probability of at least one success is 1 - (1 - 10^-6)^(230000 * 3) = 49.8% I hope this made it clear for you. I think the fallacy in your reasoning was assuming that only legitimate users can get the "secret" token, which is false. It is true for things like debit cards, where the token is stored on the card itself, hence the 4-digit PIN with 3 tries allowed is sufficient. In this case however a "secret" token is handed out to anyone who requests a code. It protects you from someone peeking into your mailbox and stealing your code, but it fails against brute forcing codes on a large number of users.
    - mszary 4y ago
      You're over complicating this. In fact it might provide a similar kind of protection the physical chip provides for debit cards. Let me explain: 1. Someone (anyone) initiates the login flow 2. The user record in a DB gets enriched with - the 6-digit OTP (sent via email) - the "secret" (shared with the initiating browser) - the current session failed attempts counter (default: 0, max: 3) - the total failed attempts counter since last successful login (default: 0, max: 20) Let's assume that you've initiated the session (hence own the "secret"), but have no access to the OTP - you will always have 3 attempts to guess the OTP before the session gets reset (a new "secret" + new OTP). So after the 3rd unsuccessful attempt you start from scratch. And at that point other means of protection might come into play based on the second counter (throttling the auth. requests on the WAF/fronting server, blacklisting IP addresses, etc.) The number of accounts you're targeting does not matter - in fact it may help other systems mentioned catch your malicious attempts sooner.
smt88 4y ago
You should take this nopassword repo down. It's a good example of why you shouldn't "roll your own" in InfoSec, and it would honestly make me skeptical of any of your other security work. It looks like you may not be using it for anything sensitive, but I'm worried that someone else might try to. As an alternative, there are many hosted services (e.g. Auth0) that are well-regarded, and I'm sure there are some self-hosted options. There seems to be at least one way to do magic links on top of Keyclock[1]. 1. https://github.com/p2-inc/keycloak-magic-link https://github.com/p2-inc/keycloak-magic-link
- aaaaaaaaaaab 4y ago
  Yep. Promoting shit like this on a public forum is borderline malicious.

deleted 4y ago

[deleted]

aaaaaaaaaaab 4y ago

So if I have 700k usernames I can pwn one of them with 50% probability. Cool! With 3 attempts allowed I only need 230k usernames, even better! The "secret" stored in the browser doesn't protect you from this, since I'm not stealing someone's code; I'm logging in from my own browser. (Of course I'm doing this via a botnet, so you won't notice it by IP address)

Isinlor 4y ago
With passwords you will get even higher probability if you just try 100 most popular passwords allowed by the service on hundreds of thousands of users. Try making password creation too difficult and now password reset will be the default authentication for a lot of users anyway.
- aaaaaaaaaaab 4y ago
  The 100 most popular passwords should already be blacklisted during registration, so it wouldn't be possible to set them as your password. I have nothing against password-reset-as-authentication aka "magic links", when done properly. And by properly I mean not using an ultra-low entropy auth code, like the parent is proposing (6 decimal digits, aka 20 bits of entropy).
joshstrange 4y ago
I'm pretty sure you are missing how they implementing this. It sounds like at time of the request to send the code the browser either generates and sends to the server (or gets from the server) a longer/more-complicated secret. Both that secret (which is probably account-specific, the one you requested login to) and the 6 digit code are required. You can't just guess the code, the code has to be combined with another account-specific token. By regenerating longer token each time a 6-digit token is required and only allowing something like 3 guesses per longer token (Before regenerating and sending a new 6-digit code) you have a secure system.
- aaaaaaaaaaab 4y ago
  No, actually I'm pretty sure you are missing why their system is insecure. But sure, let me explain it: Step 1: acquire a list of 230 000 usernames/emails. Step 2: for each username/email, launch a browser and request a login code. The login code is sent to the users' email address, and the super-ultra-secret token is stored in the browser. Step 3: for each username/email, do 3 random guesses from their respective browsers. Each guess is a Bernoulli trial with P = 10^-6. Thus the probability of at least one success is 1 - (1 - 10^-6)^(230000 * 3) = 49.8% I hope this made it clear for you. I think the fallacy in your reasoning was assuming that only legitimate users can get the "secret" token, which is false. It is true for things like debit cards, where the token is stored on the card itself, hence the 4-digit PIN with 3 tries allowed is sufficient. In this case however a "secret" token is handed out to anyone who requests a code. It protects you from someone peeking into your mailbox and stealing your code, but it fails against brute forcing codes on a large number of users.
  - mszary 4y ago
    You're over complicating this. In fact it might provide a similar kind of protection the physical chip provides for debit cards. Let me explain: 1. Someone (anyone) initiates the login flow 2. The user record in a DB gets enriched with - the 6-digit OTP (sent via email) - the "secret" (shared with the initiating browser) - the current session failed attempts counter (default: 0, max: 3) - the total failed attempts counter since last successful login (default: 0, max: 20) Let's assume that you've initiated the session (hence own the "secret"), but have no access to the OTP - you will always have 3 attempts to guess the OTP before the session gets reset (a new "secret" + new OTP). So after the 3rd unsuccessful attempt you start from scratch. And at that point other means of protection might come into play based on the second counter (throttling the auth. requests on the WAF/fronting server, blacklisting IP addresses, etc.) The number of accounts you're targeting does not matter - in fact it may help other systems mentioned catch your malicious attempts sooner.

smt88 4y ago

You should take this nopassword repo down. It's a good example of why you shouldn't "roll your own" in InfoSec, and it would honestly make me skeptical of any of your other security work. It looks like you may not be using it for anything sensitive, but I'm worried that someone else might try to. As an alternative, there are many hosted services (e.g. Auth0) that are well-regarded, and I'm sure there are some self-hosted options. There seems to be at least one way to do magic links on top of Keyclock[1]. 1. https://github.com/p2-inc/keycloak-magic-link https://github.com/p2-inc/keycloak-magic-link

aaaaaaaaaaab 4y ago
Yep. Promoting shit like this on a public forum is borderline malicious.