toonski has asked for the wisdom of the Perl Monks concerning the following question:

I'm programming some login scripts, and the issue of security came to mind. If I store a cookie with the username and password, that could easily be jacked. If I stored a cookie with a session ID and an IP bind or an encrypted pass with the ip address as the key, however, dialup users would have to re-login each time they go online, which would be a pain. Is there any way around this, any way to get cookie security and not make dial-up people have to log in each time?

Replies are listed 'Best First'.
Re: Cookie security and the like
by perrin (Chancellor) on Oct 14, 2003 at 01:19 UTC
    You're in luck, this chapter is free. Short answer: don't put the IP in the cookie, and use good crypto or a MAC (like MD5). Preferably use some kind of user ID instead of their actual login and password.
[reply]
Re: Cookie security and the like
by eric256 (Parson) on Oct 14, 2003 at 01:25 UTC

    You could store a key on your server for that username, and then encrypt there password using that key. Then store the encrypted part on there computer in a cookie, with their username.

    That whay you can check that the password matches. You could just encrypt the password with itself, but by using the key, you can reset the keys occasionaly to force users to relogin.

    The problem is no matter what you do, if you store it in a cookie then its not going to be total secure. You can make it very difficult for anyone to get the actualy password but they could still use the same coookie on a different computer to gain access.


    ___________
    Eric Hodges
[reply]
Re: Cookie security and the like
by inman (Curate) on Oct 14, 2003 at 09:22 UTC
    I have recently implemented a 'secure cookie' mechanism for storing a username and password as a temporary fix for a system that sits behind commercial single signon software. The problem being that the system that I was working with was not SSO compatible and needed a username and password.

    The workaround uses Blowfish to encrypt the username and password with some salt along with an Md5 signature. This level of encryption was deemed to be adequate since it would take some serious computing resources to crack the data and it would be significantly easier to use social engineering to get the credentials.

    I created a cookie granting application complete with login screen installed as a seperate app on an SSL secured machine. This solves the problem of how to get the users to create the cookie in the first place without passing unencrypted credentials over the network.

    The user needs a valid SSO session before any resources are served. This stops the cookie from being hijacked since the user name in the cookie are compared to the SSO username. The credentials contained in the cookie are also validated against an LDAP directory each time the user logs in and a new persistent cookie set.

    The key to the whole of this mechanism is the SSO software which does a proper job of protecteing the content but still requires the users to log on to an SSL protected form with a username and password.

    This probably doesn't help you out a great deal in terms of a practical answer but the mechanism is reasonable and could be worth copying.

    inman

[reply]
Re: Cookie security and the like
by Roger (Parson) on Oct 14, 2003 at 01:26 UTC
    If you want your login secure, you can't trust the dial-in account. Anybody could have hijacked the dial-in computer/account, but without a proper login password, he/she could not login. This means your system is more secure.

    When a user dials in, they will need to login with their user name and password. So you can use their (encrypted) dial-in username and password when you set the cookie. This way the dial-up user does not have to re-login.

[reply]

Back to Seekers of Perl Wisdom