I''m about to implement this, and I''m thinking of storing the user''s id and their hashed password in the cookie after a successful authentication. can any see an obvious security issue with this? I know the method is vulnerable to cookie theft but am i missing anything? thanks alan
On 7/27/06, Alan Bullock <liststuff@gmail.com> wrote:> > I''m about to implement this, and I''m thinking of storing the user''s id and > their hashed password in the cookie after a successful authentication. > > can any see an obvious security issue with this? I know the method is > vulnerable to cookie theft but am i missing anything? > > thanks > alan > >The only reason I could see for storing this information is to automatically log in the user based on the cookie credentials. IMHO, this is a definite security issue and I wouldn''t go with this approach and therefore wouldn''t expose this information. Just my 2 cents. -- Andrew Stone -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060727/8b61cb19/attachment.html
On Thursday 27 July 2006 12:45, Alan Bullock wrote:> I''m about to implement this, and I''m thinking of storing the user''s id > and their hashed password in the cookie after a successful > authentication.If you store their hashed password in there, I guess that means that it it spoosible to authenticate to your site knowing only the username+passwordhash? That renders the entire idea of hashing passwords ad absurdum ;) The usual solution would be to simply use sessions. By default with session cookies (destroyed when the browser is closed) and optionally ("remember me") with long expiry times (14 days?) Still not really secure, but (a) it''s (also) optional, so the users can be blamed if something goes wrong *g*, and (b) session IDs change more often than passwords. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://wrath.rubyonrails.org/pipermail/rails/attachments/20060728/5414aadf/attachment.bin
On 7/27/06, Alan Bullock <liststuff@gmail.com> wrote:> I''m about to implement this, and I''m thinking of storing the user''s id and > their hashed password in the cookie after a successful authentication. > > can any see an obvious security issue with this? I know the method is > vulnerable to cookie theft but am i missing anything?Don''t include the password in any form, just as a precaution. And add a timestamp, you really don''t want such a cookie to be valid forever. Isak
I was actually googling for persistent logins just last night! these links will redierct you to some pages on persistent logins i found useful... http://ebtag.com/110 http://ebtag.com/111 ebtag was my brother and my RailsDay entry :] gustav@rails.co.za Gustav Paul itsdEx.com -- Posted via http://www.ruby-forum.com/.
I was actually googling for persistent logins just last night! these links will redirect you to some pages on persistent logins i found useful... espescially /110. uses the database to store links to cookies etc. looks really cool! http://ebtag.com/110 http://ebtag.com/111 ebtag was my brother and my RailsDay entry :] gustav@rails.co.za Gustav Paul itsdEx.com -- Posted via http://www.ruby-forum.com/.
Alan Bullock wrote:> I''m about to implement this, and I''m thinking of storing the user''s id > and > their hashed password in the cookie after a successful authentication. > > can any see an obvious security issue with this? I know the method is > vulnerable to cookie theft but am i missing anything? >For my site, I implemented rememberMe by creating a cookie with the user''s id, an md5 signatute for verification, and a timestamp for expiration. If the cookie is there and the signature matches and the timestamp hasn''t lapsed I ''remember'' them. In my case, its only for the purposes of personalization that I remember them. If they try to modify their account or anything that could be destructive, I force them to login for that session with a password. I avoid storing the password in a cookie (in any form) because I wasn''t comfortable with it from a security perspective. I''m assuming most of my users want to be remembered for the sake of convenience. -- Posted via http://www.ruby-forum.com/.
Alan Bullock wrote:> I''m about to implement this, and I''m thinking of storing the user''s id > and > their hashed password in the cookie after a successful authentication. > > can any see an obvious security issue with this? I know the method is > vulnerable to cookie theft but am i missing anything? > > thanks > alanShort answer (I''m a security geek): never, but never, store anything that can be associated with any user in a session cookie, including password hashes. Only use session identifiers containing a significant amount of high-quality random bits. In persistent cookies, the rule is stricter: never, but never, store anything at all that can be associated with a user, including random session identifiers. If you relax this policy in any way (usual justifications are: "my site doesn''t really have anything confidential on it") you''re taking the risk of compromising the integrity of your site (which may indeed be an acceptable risk) or your users'' identities (which may be a risk whose acceptability is not entirely yours to decide). I often work with sites that must be load-balanced across many servers. In these cases, the obvious difficulty with session identifiers that contain only randomness is passing them around from one server to another. Session stickiness is one pretty decent answer to this, assuming you don''t restart your server processes often. Another answer is to store sessions in a DBMS, which I don''t like because now your DBMS and your server-farm''s LAN topology just became scalability constraints. -- Posted via http://www.ruby-forum.com/.