What happens when authy goes down? Your users just don't log in? On Friday, May 3, 2013, Nik Martin wrote:
> I deleted this and reposted, because I forgot to address one of your > questions, which I did in this edit: > > I'm going to vastly over simplify this, but it holds up if you have any > HTTP/Node.js experience. I have closely examined 2 authentication schemes: > Cloudstack, Amazon AWS, and both implementations are WAY simpler than you > think, and are as good as implementing two-legged OAUTH which both are very > similar to. You'll WANT to do this yourself as (my opinion) you REALLY > need to understand how your app is authenticating, and besides it's easy. > > http://www.thebuzzmedia.com/**designing-a-secure-rest-api-** > without-oauth-authentication/<http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/> > > > This link you posted is 95% of how AWS and Cloudstack do it. The main > difference is that they use a stored API Key and API Secret that are > associated with your user ID. That's fine, but then you have to store > stuff on the phone, or pass the secret over the wire (NEVER NEVER NEVER). > Why not use The user ID and Password (with complexity rules) as the API > key and Secret? This way, they are only stored in the app's memory, and > when the app goes away, the "session" dies, like it should. The phone also > has a screen lock, right? So the user is partially responsible for the > security of his data as he should be. Also, MFA is 100% required IMO if you > are going to actually secure from man-in-the-middle. > Authy<https://www.authy.com/> is > cheap, and easy, brain-dead-easy to implement. OK, on to some code: > https://gist.github.com/**nikmartin/5499838<https://gist.github.com/nikmartin/5499838> > That's it. Do that on both client and server for EVERY REST call, and > you've done it, with very high security. Now, to go even further, taking > the MFA concept of a very short lived token, AFTER signing the request, add > a UNIX UTC timestamp to your payload, and on the server, check it to ensure > it's within x seconds of the server time. This prevents replay attacks. > One more add-on, I think from that buzzmedia article, is to also add the > URI and HTTP verb into he signature, again to prevent hijacking a signed > request to replay against another URI/VERB, like hijacking "getUserAccount" > to "deleteUser", etc. > > > Password storage: this can be pretty simple as well, as simple as > concatting the password with the username, then salting the password with > that. So when the user authenticates, he can salt the password on the > client before sending, and you can store it salted. Salts don't have to be > secret, they just guard against rainbow attacks, and the client knows the > salt, because it's his username+password > > If you or anyone else can punch a hole in that, be my guest, as I'm > implementing this my self at this very moment with Node, Android, > mongoose+mongoDB, and Authy, and haven't found a simpler scheme yet. > > > Nik > > On Wednesday, May 1, 2013 12:20:24 PM UTC-5, Alan Fay wrote: > > Hello! > > I'm trying to develop a REST API using node.js, to support an Android app. > I've been able to find several resources on the web, however, most of the > examples I come across fall into two camps: > 1) Basic authentication over HTTPS > 2) OAuth > > I don't want to do basic authentication over HTTPS with a username and > password, because in the Android app, I have it setup to store a username > and token via the AccountManager (they seem to have taken down reference to > the code on Android's site; my implementation is very similar the sample > code that ships with the SDK: *android-sdk-linux/samples/ > android-17/SampleSyncAdapter* except I'm not using any of the Sync > features). > > I don't want to use OAuth because I am not sure we can count on users to > have accounts with Google or some other third-party OAuth provider. > > This is my first round at implementing web authentication; from what I'm > reading, the steps go something like this: > - [Service] Administrator creates an account with a username and a > generated strong code is stored temporarily in the user record; emailed to > user > - [App] User selects account and enters username and code, plus password > of their choice, into the form > - [App] Basic authentication over HTTPS sends over username, code, and > password (just this once) > - [Service] Stores random salt and password hash in the user record, and > the generated token (a) > - [Service] Replies back to App with the token > - [App] Username and token is stored via AccountManager > > Then, > - [App] User sends username and token to service (b) > - [Service] *authenticates* the user if the token matches and is not > expired (c) > - [App] User can access the various REST API calls (d) > > In this way, the password is never stored on the Android device or in the > database. When the token expires, then User re-enters password. The User > can request a password reset, which generates a strong code again and the > process starts from the top. > > My questions (referenced above) are: > (a) Should the generated token be stored on the user record, or in a > separate table? My thinking for a separate table/collection would be to > have a background process that could remove expired tokens; keeping this > information separate from the user record; or perhaps a user could have a > valid reason to have multiple different tokens (one on the phone, another > on the tablet). > (b) Is this simply done through basic authentication over HTTPS, sending > the username and token (in place of password)? > (c) I've seen examples of node.js code setting values on request.session; > effectively, marking the session as authenticated. Is this specific to > browsers/cookies and/or does it work when communicating to Android? > (d) Kind of an extension of (c), does the username/token have to be sent > every time, or can I reference something like the > request.session.authorized value? > > Also: > - Does anyone know of a good working example of a node.js REST API > implementation for an Android app? Sometimes it's easier to just learn > from code. > - Is there working example code of the node dependencies I see referenced > everywhere (everyauth, connect-auth, passport) being used with an Android > app? Most seem to implement OAuth solutions. > - Any security/implementation pitfalls with this approach? > > References: > * [The Definitive Guide to Forms-based Website Authentication](http://** > stackoverflow.com/a/477578/**172217<http://stackoverflow.com/a/477578/172217> > ) > * [Designing a Secure REST (Web) API without OAuth](http://www.** > thebuzzmedia.com/designing-a-**secure-rest-api-without-oauth-** > authentication/<http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/> > ) > * [How to Implement a Secure REST API with node.js](http://stackoverflow.* > *com/a/15500784/172217 <http://stackoverflow.com/a/15500784/172217>) > * [RESTful > Authentication](http://**stackoverflow.com/a/7158864/**172217<http://stackoverflow.com/a/7158864/172217> > ) > * [Securing my node.js App REST API](http://stackoverflow.com/** > a/9126126/172217 <http://stackoverflow.com/a/9126126/172217>) > * [Connect Session Middleware](http://www.**senchalabs.org/connect/** > session.html <http://www.senchalabs.org/connect/session.html>) > * [Secure Salted Password > Hashing](<http://crackstation.net/hashing-security.htm> > > -- > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to > nodejs@googlegroups.com<javascript:_e({}, 'cvml', 'nodejs@googlegroups.com');> > To unsubscribe from this group, send email to > nodejs+unsubscr...@googlegroups.com <javascript:_e({}, 'cvml', > 'nodejs%2bunsubscr...@googlegroups.com');> > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > > --- > You received this message because you are subscribed to the Google Groups > "nodejs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to nodejs+unsubscr...@googlegroups.com <javascript:_e({}, 'cvml', > 'nodejs%2bunsubscr...@googlegroups.com');>. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
