no password login

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

User avatar
s.dot
Tranquility In Moderation
Posts: 5001
Joined: Sun Feb 06, 2005 7:18 pm
Location: Indiana

no password login

Post 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)
Set Search Time - A google chrome extension. When you search only results from the past year (or set time period) are displayed. Helps tremendously when using new technologies to avoid outdated results.
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post 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 :)
User avatar
n00b Saibot
DevNet Resident
Posts: 1452
Joined: Fri Dec 24, 2004 2:59 am
Location: Lucknow, UP, India
Contact:

Post 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:
User avatar
aaronhall
DevNet Resident
Posts: 1040
Joined: Tue Aug 13, 2002 5:10 pm
Location: Back in Phoenix, missing the microbrews
Contact:

Post 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
User avatar
s.dot
Tranquility In Moderation
Posts: 5001
Joined: Sun Feb 06, 2005 7:18 pm
Location: Indiana

Post by s.dot »

aaronhall wrote:Definately -- set the cookie from PHP under SSL only
This forum doesn't.
Set Search Time - A google chrome extension. When you search only results from the past year (or set time period) are displayed. Helps tremendously when using new technologies to avoid outdated results.
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post 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"...;)
User avatar
volka
DevNet Evangelist
Posts: 8391
Joined: Tue May 07, 2002 9:48 am
Location: Berlin, ger

Post 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']) . "'";
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Post 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.
User avatar
volka
DevNet Evangelist
Posts: 8391
Joined: Tue May 07, 2002 9:48 am
Location: Berlin, ger

Post 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?
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Post 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.
User avatar
volka
DevNet Evangelist
Posts: 8391
Joined: Tue May 07, 2002 9:48 am
Location: Berlin, ger

Post 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?
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post 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...
User avatar
s.dot
Tranquility In Moderation
Posts: 5001
Joined: Sun Feb 06, 2005 7:18 pm
Location: Indiana

Post 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
Set Search Time - A google chrome extension. When you search only results from the past year (or set time period) are displayed. Helps tremendously when using new technologies to avoid outdated results.
wei
Forum Contributor
Posts: 140
Joined: Wed Jul 12, 2006 12:18 am

Post 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.
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post 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...;).
Post Reply