5 ms·

Tried to sign up but I'm not a Google Authenticator fan. You should consider other auth methods... like good ol' passwords.

andrewstuart 8y ago
Yeah I hear you. Here's what got me to this point: The framework that I started out on had a zero password system. But that's not secure enough, so I thought "do I go traditional usernames/passwords"? I then decided to go with the Google Authenticator instead of passwords because so many systems get hacked these days that it seems maybe its a better idea to have no passwords. But then I launched, a little hesitant about my decision, and of course your email backs up the idea I should have just stuck with usernames and passwords. I'll have to think about what to do about it. thanks for the feedback.
ravenstine 8y ago
I've had success with the "password less" approach of sending a magic link in an email.
- czbond 8y ago
  Question: When you implement this, at what point (if any) do you have a user create a password?
  - thaumasiotes 8y ago
    There are companies so freaked out by the idea of leaking user passwords that they just don't use any auth method other than a link sent to the user's email address. A couple major considerations if you're using that approach: - When do those links expire? - Do you keep logs of the pages that people request from your server? An unexpired link compromises the user just as much as a password leak would have, since those links _are_ the user passwords. But server logs generally aren't tied down as tightly as a more obviously sensitive password database would be. The nightmare scenario here is "every time the user needs to log in, we generate a new password for them, and every password stays valid forever. Whenever anyone actually does log in, we record their password in our server logs, available at www.ourcompany.com/debug/ . Then we send it to a dozen different third-party analytics providers."
    - ravenstine 8y ago
      Ideally, you'd want those links to expire after one use or after a few minutes, and you'd have some means of preventing replay-attacks. (a temporary token stored on the client that gets sent to the server during the email dispatch) Assuming every channel is encrypted, an unexpired link isn't as easily compromised as a password.
rhn_mk1 8y ago
What's the issue with OATH? It's a standard with widely available tools, and it offers additional security compared to a password.
FabHK 8y ago
FWIW, Authy has worked for me anywhere Google Authenticator has been asked for, and is better, it seems to me (multi device, online backups, etc.).
thaumasiotes 8y ago
> I'm not a Google Authenticator fan. You should consider other auth methods... like good ol' passwords But Google Authenticator IS a password system. You're just not expected to memorize the password.

andrewstuart 8y ago

Yeah I hear you. Here's what got me to this point: The framework that I started out on had a zero password system. But that's not secure enough, so I thought "do I go traditional usernames/passwords"? I then decided to go with the Google Authenticator instead of passwords because so many systems get hacked these days that it seems maybe its a better idea to have no passwords. But then I launched, a little hesitant about my decision, and of course your email backs up the idea I should have just stuck with usernames and passwords. I'll have to think about what to do about it. thanks for the feedback.

ravenstine 8y ago

I've had success with the "password less" approach of sending a magic link in an email.

czbond 8y ago
Question: When you implement this, at what point (if any) do you have a user create a password?
- thaumasiotes 8y ago
  There are companies so freaked out by the idea of leaking user passwords that they just don't use any auth method other than a link sent to the user's email address. A couple major considerations if you're using that approach: - When do those links expire? - Do you keep logs of the pages that people request from your server? An unexpired link compromises the user just as much as a password leak would have, since those links _are_ the user passwords. But server logs generally aren't tied down as tightly as a more obviously sensitive password database would be. The nightmare scenario here is "every time the user needs to log in, we generate a new password for them, and every password stays valid forever. Whenever anyone actually does log in, we record their password in our server logs, available at www.ourcompany.com/debug/ . Then we send it to a dozen different third-party analytics providers."
  - ravenstine 8y ago
    Ideally, you'd want those links to expire after one use or after a few minutes, and you'd have some means of preventing replay-attacks. (a temporary token stored on the client that gets sent to the server during the email dispatch) Assuming every channel is encrypted, an unexpired link isn't as easily compromised as a password.

rhn_mk1 8y ago

What's the issue with OATH? It's a standard with widely available tools, and it offers additional security compared to a password.

FabHK 8y ago

FWIW, Authy has worked for me anywhere Google Authenticator has been asked for, and is better, it seems to me (multi device, online backups, etc.).

thaumasiotes 8y ago

> I'm not a Google Authenticator fan. You should consider other auth methods... like good ol' passwords But Google Authenticator IS a password system. You're just not expected to memorize the password.