3 ms·

1) If Clef ever goes away, you still own all of the data about your users, including their email, and you can easily send them a link to create a password for y

1) If Clef ever goes away, you still own all of the data about your users, including their email, and you can easily send them a link to create a password for your site. 2) You are depending on our uptime, and of course this is a huge priority for us. 3) As we've said elsewhere, Clef is two-factor authentication and a lost phone is both protected and easy to deactivate. Thanks for pointing out where we can be more clear in addressing these potential problems, but these security problems are things which we have considered and solved for.

cheald 14y ago
Regarding the first point, that is true, assuming that the user used a real email and didn't typo it, still has access to that email account, etc. Delegated auth is wonderful, but hitching your auth wagon to a new company makes me nervous. That's not your fault, and it's not something I expect a solution for, because it's just the natural state of startup affairs. I do hope you guys get big enough that it's not a concern! I retracted the 4th point, since it was a bit unclear, but my concern was that since you're almost always going to be sharing the same network with the mobile device and authenticating device, you can get both the data out from the phone and the data in from the Javascript; one of the marketing pieces is "log in once, you're logged in everywhere", which means that if I can steal whatever cookie gets set, I've got full access. This is a problem that the big delegated auth players (Google, Facebook) work very hard to solve by making sure that even a slight change in access patterns means session invalidation or a reauthentication challenge, because if you can steal a Facebook or Google session, the same concerns apply. Some kind of assurance that you all employ the same kinds of paranoid measures would be great.
- brennenHN 14y ago
  That's a really good point about the cookie theft. We sign our cookies to make sure that they're inaccessible to others, but making sure they're non-transferrable/stealable is worth more consideration.

cheald 14y ago

Regarding the first point, that is true, assuming that the user used a real email and didn't typo it, still has access to that email account, etc. Delegated auth is wonderful, but hitching your auth wagon to a new company makes me nervous. That's not your fault, and it's not something I expect a solution for, because it's just the natural state of startup affairs. I do hope you guys get big enough that it's not a concern! I retracted the 4th point, since it was a bit unclear, but my concern was that since you're almost always going to be sharing the same network with the mobile device and authenticating device, you can get both the data out from the phone and the data in from the Javascript; one of the marketing pieces is "log in once, you're logged in everywhere", which means that if I can steal whatever cookie gets set, I've got full access. This is a problem that the big delegated auth players (Google, Facebook) work very hard to solve by making sure that even a slight change in access patterns means session invalidation or a reauthentication challenge, because if you can steal a Facebook or Google session, the same concerns apply. Some kind of assurance that you all employ the same kinds of paranoid measures would be great.

brennenHN 14y ago
That's a really good point about the cookie theft. We sign our cookies to make sure that they're inaccessible to others, but making sure they're non-transferrable/stealable is worth more consideration.