Page 1 of 2

no password login

Posted: Fri Oct 06, 2006 10:42 pm
by s.dot
..... how does phpbb allow users to be automatically logged in without entering their password each time? obviously this would be in a cookie... and isn't it a security issue to store passwords in a cookie (obviously not raw)

(didn't know wheahter to put this here or security)

Posted: Fri Oct 06, 2006 11:16 pm
by alex.barylski
It's sorta a security risk, depends on the implementation...

I've seen some CMS applications which actually use a poor mans SSL using javascript for client side encryption and PHP for decryption. This emulates SSL's public key encryption.

I personally can't be bothered relying on javascript always being available, so instead I pass the user/pass over to the server once in plain text...but encrypt with blowfish on the server side. The password must remain secret on your server somewhere outside docroot.

Then your scripts merely have to get the encrypted cookie, decrypt it and compare the user/pass to the database...

in this way it's actually more secure than normal, as you only once pass the user/pass over the wire in plain text

Problems:
- If you ever need to change the server side password (monthly or randomly, etc) you either need to invalidate the encrypted cookie...for me thats not really a big deal if it allows users to auto login for up to a month...and securely to boot...

Blowfish is an excellent algorithm for this. http://www.schneier.com/blowfish.html

Cheers :)

Posted: Sat Oct 07, 2006 12:27 am
by n00b Saibot
Hockey wrote:so instead I pass the user/pass over to the server once in plain text...
I would like to put Sniffer to good use here ;) Hockey's passwords are in danger :lol:

Posted: Sat Oct 07, 2006 12:41 am
by aaronhall
n00b Saibot wrote:
Hockey wrote:so instead I pass the user/pass over to the server once in plain text...
I would like to put Sniffer to good use here ;) Hockey's passwords are in danger :lol:
Definately -- set the cookie from PHP under SSL only

Posted: Sat Oct 07, 2006 1:19 am
by s.dot
aaronhall wrote:Definately -- set the cookie from PHP under SSL only
This forum doesn't.

Posted: Sat Oct 07, 2006 2:15 am
by Maugrim_The_Reaper
You can still avoid plain text without SSL by using javascript to send a unique salted password hash. Doesn't work without Javascript but its easy to allow the system degrade back to plain text.
Hockey wrote:I personally can't be bothered relying on javascript always being available, so instead I pass the user/pass over to the server once in plain text...but encrypt with blowfish on the server side. The password must remain secret on your server somewhere outside docroot.
Dismissing javascript so readily is a bit harsh. It is available on the vast majority of browsers installed. Dismissing it and removing its potential benefit to end users is a poor excuse just because there's a few exceptions in the crowd. Do you know how easy it is to sniff network traffic without SSL present? Do a google search for "sniffer"...;)

Posted: Sat Oct 07, 2006 6:30 am
by volka
phpBB sets a cookie that contains the userid and a autologinid
include/session.php

Code: Select all

if (isset($sessiondata['autologinid']) && (string) $sessiondata['autologinid'] != '' && $user_id)
		{
			$sql = 'SELECT u.* 
				FROM ' . USERS_TABLE . ' u, ' . SESSIONS_KEYS_TABLE . ' k
				WHERE u.user_id = ' . (int) $user_id . "
					AND u.user_active = 1
					AND k.user_id = u.user_id
					AND k.key_id = '" . md5($sessiondata['autologinid']) . "'";

Posted: Sat Oct 07, 2006 6:38 am
by Chris Corbyn
Couldn't this be better handled with a challenge/response type system whereby if the user has requested auto-login the challenge is generated then stored in the DB, and the response generated and put in a cookie. Now you can only auto-login if the DB has a challenge and the cookie contains a correct response. No actual passwords stored anywhere.

Posted: Sat Oct 07, 2006 6:45 am
by volka
d11wtq wrote:whereby if the user has requested auto-login the challenge is generated then stored in the DB
when autologin is activated or refreshed the autologinid changes.
How would you handle the challenge/response and what data would be required and handled at which side?

Posted: Sat Oct 07, 2006 7:10 am
by Chris Corbyn
What I mean, is that like standard challenge/response the server generates a challenge. Now, the client generates a response. Under normal cirumstances that challenge/response pair would only work for that session but if the user has asked for "Remember password" then the response is dumped to a cookie as well as sent to the server. The server then stores the challenge in the DB so it can be re-used.

I'm not sure what you're asking; I assume you understand how to code a challenge/response login system for web apps. The basic process is to generate a hash on the server based upon time, server name and a random factor.

The client then uses that challenge to create another hash based upon username, password and the challenge to produce a response. Only this response is sent back to the server; not even a username is sent. The server then uses some algo on the challnege to match the response to a record in the DB for authentication. It's most secure if the challenge is a one-time-use only hash but re-using it for auto-login is still more secure than storing plain-text passwords. Neither a challenge, nor a response actually means anything to anybody but the server, and even then it can only use it find a DB record... it still doesn't know the password.

Posted: Sat Oct 07, 2006 7:18 am
by volka
The client then uses that challenge to create another hash based upon username, password and the challenge to produce a response.
And where would you let a board like phpBB store the plain-text username and password client-side?

Posted: Sat Oct 07, 2006 6:32 pm
by alex.barylski
Dismissing javascript so readily is a bit harsh. It is available on the vast majority of browsers installed
But not *every*

Authentication isn't exactly an operation where you want almost all of your users to be able to complete...it's either do or don't, there is no try...

If someone can't login...geuranteed your getting support calls or worse yet complaints or the worsetestest...complete objection to using your application period. :P

It's not like, using javascript to make data entry a little more friendly...or something related to usability, etc...

If you don't have javascript available to encrypt, then passwords sent in the clear, wouldn't get decrypted properly and you user wouldn't be authenticated. Period.

Poor man's SSL (javascript) is ok under vertical market software I suppose, but I wouldn't ever implement anything like that myself, because it's fixing a round hole using a square block...if security is that important...use SSL.
Dismissing it and removing its potential benefit to end users is a poor excuse just because there's a few exceptions in the crowd
Hmmmm...I can't agree...considering authentication again, isn't something that can *maybe* work for most users...it either works or it doesn't...

Sure you could use work arounds (for those who didn't have javascript) to allow either, but again, adding bloat and complexity, when, if security was that important, you should be using SSL...
Do you know how easy it is to sniff network traffic without SSL present? Do a google search for "sniffer"...
That easy eh? I challenge you then, to capture any text I send over the wire with MSN, etc...Perhaps easy in principle but much more difficult in practice my friend. Getting your packet sniffer where it has to be in order to "sniff" packets is a whole different story...

I just realized a fault in my own approach :P

Glad I haven't used that technique on anything serious :lol:

bah...back to the drawing board and investigation into public key encryption again...

I wonder...if you stored the IP of the authenticated user in with the user/pass upon login...so long as the IP address stayed the same, which it should under most circumstances (unless on dialup) you could decrypt on the server, compare the IP and if the IP were the same, allow authentication.

This would prevent someone from simply copy/pasting encrypted user/pass pairs into their own cookies and assuming someone's identity, as they would likely be hard pressed being capable of guessing the any users IP address. Perhaps other userAgent data as well to further add entropy...???

Hmmmm...that could work :P Not perfect, but a helluva lot better than storing user/pass in the plain I would think...

Posted: Sat Oct 07, 2006 9:29 pm
by s.dot
This seems more complicated than I was thinking. Definately not a big enough pro-side for me to consider it, with it being such an optional feature. I don't mind having ppl login on every visit, and they don't mind it, either. However, given the responses.... seems very interesting. 8O

Posted: Sun Oct 08, 2006 1:13 am
by wei
with the feature of "auto login" or the "remember me" you need to weight up the convenience and security trade off factors. The auto login feature should only be optional. For tasks that are critical, such as changing the password, the user should always be asked to entered their password or other details.

Posted: Sun Oct 08, 2006 7:30 am
by Maugrim_The_Reaper
Poor man's SSL (javascript) is ok under vertical market software I suppose, but I wouldn't ever implement anything like that myself, because it's fixing a round hole using a square block...if security is that important...use SSL.

Quote:
Dismissing it and removing its potential benefit to end users is a poor excuse just because there's a few exceptions in the crowd


Hmmmm...I can't agree...considering authentication again, isn't something that can *maybe* work for most users...it either works or it doesn't...

Sure you could use work arounds (for those who didn't have javascript) to allow either, but again, adding bloat and complexity, when, if security was that important, you should be using SSL...
Check out my signature for a relevant tutorial. It's quite simple to create a JS powered challenge/response system which gracefully falls bacl to plain text when a client does not support javascript. For the record, an SSL cert. is expensive and a C/R system without SSL is a backup. I fail to see any significant disadvantage, but I do see some very good security benefits.

Like I said, non-JS clients are a minority - they shouldn't dictate security practice for the majority when viable alternatives exist which *all* clients can still operate under. I don't suggest leaving non-JS clients in the dust if they don't support a feature - but C/R does not fall under this category...;).