Comments

[orefalo]

First, good job. I learned a lot about meteor from browsing your code.

Just a few comments on your solution

*. Probably most important: This solution is extremely weak without SSL
*. Make the code generic so that is can be used with password, but also other authentication mechanism
*. I am not sure how to achieve this with websockets, but typically the signed ticket is regenerated on every round trip.
*. Expiration, you should add a way for the ticket to expire. Either with the above, where the ticket is only available for the next request - or by adding a date somewhere
*. MD5 sounds weak, prefer at least SHA1

Last but not least, meteor is working hard on auth. Might be a good idea to see how they do it.

[matb33]

Thanks for writing!

• Agreed, and in fact it is intentionally weak without SSL. It seems the general consensus (from my own research efforts) is that SSL (so, at least the login part under https) is the best candidate for securing the login/password transmission. Any other method (encrypting client-side etc) is consistently discouraged.
• Good point. I'm hoping Meteor's solution does this for me, as I trust their take on auth will be more complete and abstracted for multiple scenarios. I don't want to duplicate too much work -- I just needed some kind of decent auth today
• That's interesting, and it makes sense. I'll add that, unless Meteor's auth branch comes out before I make this change
• Totally agree. Though again, may not be worth the effort in terms of duplication of effort wrt to Meteor's auth
• I only use HMAC-MD5 for generating the signed token. Bcrypt is what encrypts the password. Using MD5 or SHA1 and other flavors for encrypting passwords is considered very bad practice

FYI, I followed as much as I could from this post on SO