July 6, 2008 12:34am pdt

1. hielo 1,009,885
2. hernst42 506,707
3. Roonaan 274,181
4. logudotcom 267,638
5. angelIII 267,393
6. Ray_Paseur 219,074
7. RQuadling 203,916
8. nplib 195,740
9. routinet 186,752
10. Squinky 169,643
11. glcummins 148,739
12. Xyptilon2 135,889
13. dr_dedo 124,091
14. ddrudik 119,148
15. darron_c... 119,116

1. hernst42 2,072,785
2. Roonaan 1,988,500
3. TeRReF 1,246,209
4. hielo 1,050,410
5. Diablo84 1,046,676
6. angelIII 867,599
7. Squinky 866,248
8. RQuadling 745,618
9. steelseth12 644,573
10. glcummins 635,652
11. snoyes_jw 589,263
12. ldbkutty 468,085
13. Batalf 452,611
14. nizsmo 423,250
15. Zyloch 420,026

05.09.2008 at 07:43PM PDT, ID: 23391216 | Points: 500

	[x] Attachment Details

Security with cookies

Zones: PHP Scripting Language, Miscellaneous Security

If I use cookies to remember users and auto log them in when they visit my site, do I run a security risk? Can someone steal the cookie and login without having to know the password? Is there a way around this problem?

Start your free trial to view this solution

Question Stats

Zone: Web Development

Question Asked By: ilakshmir

Question Asked On: 05.09.2008

Participating Experts: 5

Points: 500

Translate:

Loading Advertisement...

Microsoft

Internet Protocols
Applications

Development
OS

Hardware
Windows Security

Apple

Operating Systems
Hardware

Programming
Networking

Software

Internet

Search Engines
File Sharing
WebTrends / Stats
Spy / Ad Blockers

Web Browsers
New Net Users
Web Development
Chat / IM

Anti Spam
Web Servers
Anti-Virus
Email Clients

Gamers

Tips
Online / MMORPG
Puzzle
Emulators

Action / Adventure
Role Playing
Consoles
Game Programming

Strategy
Sports
Misc
Computer Games

Digital Living

Hardware
New Net Users
New Users

Software
Digital Music
Gaming World

Home Security
Apple
Networking Hardware

Virus & Spyware

Vulnerabilities
IDS
Encryption
Anti-Virus

Operating Systems Security
Software Firewalls
WebApplications
Cell Phones

Operating Systems
Internet
Hardware Firewalls

Hardware

Handhelds / PDAs
Displays / Monitors
Components
Networking Hardware

Peripherals
Laptops/Notebooks
Storage
Servers

Desktops
New Users
Misc
Apple

Software

System Utilities
Industry Specific
Network Management
Photos / Graphics
Page Layout
VMWare
Misc
Web Development

OS
CYGWIN
Voice Recognition
Message Queue
Quality Assurance
Security
Firewalls
MultiMedia Applications

Development
Database
Office / Productivity
Business Management
OS/2 Apps
Server Software
Internet / Email

ITPro

OS
Storage
Encryption
Operating Systems Security
Apple Hardware
Laptops & Notebooks
Servers
Networking Hardware
Peripherals

Devices
Displays / Monitors
WebTrends / Stats
Search Engines
Firewalls
WebApplications
IDS
Vulnerabilities
Email Clients

File Sharing
Spy / Ad Blockers
Web Browsers
Web Servers
Networking
Anti-Virus
Chat / IM
Anti Spam

Developer

Web Servers
Web Browsers
Game Programming
Dev Tools
Industry Specific
Office / Productivity

Database
CYGWIN
Web Development
Search Engines
File Sharing
WebTrends / Stats

Programming
Content Management
Application Servers
Protocols

Storage

Removable Backup Media
Storage Technology
Servers

Grid
Remote Access
Backup / Restore

Misc
Hard Drives

Miscellaneous
Security
Development
Linux
VMWare

MainFrame OS
Unix
Apple
OS / 2
AS / 400

BeOS
Microsoft
VMS / OpenVMS

Database

Oracle
Miscellaneous
MySQL
Software
Sybase
Contact Management
PostgreSQL
Data Manipulation
Clarion
InterSystems Cache

Siebel
MUMPS
OLAP
SQLBase
SAS
GIS & GPS
4GL
Berkeley DB
DB2
Informix

Interbase / Firebird
FoxPro
Reporting
LDAP
Filemaker Pro
MS SQL Server
dBase
MS Access

Security

Misc
Web Browsers
Software Firewalls
Operating Systems Security
File Sharing

Spy / Ad Blockers
Vulnerabilities
WebApplications
IDS
Anti-Virus

Encryption
Anti Spam
Email Clients
VPN
Chat / IM

Programming

Editors IDEs
Installation
Handhelds / PDAs
Multimedia Programming
System / Kernel

Algorithms
Game
Signal Processing
Project Management
Open Source

Database
Misc
Languages
Processor Platforms
Theory

Web Development

Scripting
Blogs
Web Servers
Software
Search Engines
Web Graphics
Images

Internet Marketing
Images and Photos
Components
Document Imaging
Web Languages/Standards
Illustration
WebApplications

Fonts
WebTrends / Stats
Authoring
Digital Camera Software
Miscellaneous

Networking

Protocols
Apple Networking
Network Management
Message Queue
Application Servers
Content Management
File Servers
Email Servers
Misc
Java Editors & IDEs

Wireless
Networking Hardware
Backup / Restore
System Utilities
ISPs & Hosting
Web Servers
Storage Technology
Removable Backup Media
Servers
Broadband

Grid
OS / 2
Novell Netware
Unix Networking
Windows Networking
Security
Telecommunications
Operating Systems
Linux Networking

Other

Community Advisor
Lounge
Community Support
New Net Users

Philosophy / Religion
Math / Science
Miscellaneous
URLs

Expert Lounge
Politics
Puzzles / Riddles

Community Support

Suggestions
New to EE
New Topics
Community Advisor

CleanUp
Announcements
General

Feedback
Input
EE Bugs

05.09.2008 at 09:49PM PDT, ID: 21537887

SideFX250:

Yes, you run a security risk primarily based on browser vulnerabilities.

What you can do to mitigate the risk is to fingerprint the Users as much as possible.

For example, the User-Agent in the request headers:

                       
             //When a user returns
 
$userAgent = md5($_SERVER['HTTP_USER_AGENT');
 
if($_SESSION['userAgent'] != $userAgent)
    header( 'Location: /login.php');
 
//Restore the session.

Open in New Window

05.10.2008 at 12:33AM PDT, ID: 21538133

Rank: Master

BrianGEFF719:

@SideFX250: I think he is talking about client side persistent cookies and not session cookies.

@ilakshmir:
It's really not a big deal. In fact experts exchange does exactly what you're talking about. For security you should store a Salted & Hashed password, but other than that don't worry too much about security unless your dealing with heavily with financial transactions.

-Brian

05.10.2008 at 12:59AM PDT, ID: 21538179

Rank: Wizard

PowerIT:

The main risk is that through a cross site scripting (XSS) attack someone can steal the cookie of one of your users and then use it.
Defense against XSS: a well written application / website which verifies and validates ALL input (that inludes URL parameters, input fields and data coming from the database).

J.

05.10.2008 at 05:51AM PDT, ID: 21538850

Rank: Guru

Ray_Paseur:

If you want to mitigate the XSS stolen cookie attack, you can save the remote address (NOT in the cookie, but in the backing record) and if it does not match the current remote address, call for a password. If you place this check in the correct location in the hierarchy of your security checks it will be relatively unobtrusive for legit users.

Although all headers can be forged, a decent combination of user agent, remove address and user-id can be cobbled together and hashed with MD5 or SHA1. Store this hash in your cookie and in your data base, and it will make it harder to present false credentials successfully.

Also, google "Chris Shifflett" (security expert, not Foo Fighter) and read up on his security blog - very good stuff!

HTH, ~Ray

05.10.2008 at 08:34AM PDT, ID: 21539390

Rank: Master

Rok-Kralj:

If you use same login cookie for every user to check if he should visit site
like ALLOWED = YES, then it is a risk, because everyone can easily add this cookie to the browser.

If you use different cookie for every user, then it's ok. But it must be something that others can't guess.
Like users name would be bad idea, because I can simply guess (Jack, John, Joanne)

05.11.2008 at 12:22AM PDT, ID: 21541692

SideFX250:

You really don't have to store anything beyond the session id in the cookies.

A hashed password, even if salted is a bad idea :)

The rest can be stored in the database or file system and restored to $_SESSION.

The restored session data should have the fingerprint(s).

When a user returns, make use of the $_COOKIE['PHPSESSID'] as well as the server-side data identifying the user.

05.11.2008 at 12:27AM PDT, ID: 21541699

SideFX250:

for example $_SESSION['fingerprint'] :)

05.11.2008 at 05:17PM PDT, ID: 21544028

Rank: Master

BrianGEFF719:

Personally, I feel that storing a PHP Session ID in a persistent cookie is a bad idea for many reasons. Firstly, it opens up the potential of XSS attacks and session hijacking. PHP now supports HttpOnly session cookies which don't make the session id available to javascript which greatly reduces the possibility of session hijacking. Secondly, you have to have an extremely long session time out, in orders of several days or weeks, a lot of unnecessary session data being stored on the server. Finally, sessions should be just that...sessions. They weren't really designed to be extended sessions, they were designed to keep track of what a user is doing _now_ on your site, not what they were doing last week....just my opinion, although I do imagine many would disagree with the latter statement.

Also, storing the users IP address as a form of session validation probably isn't feasible. Many users still have dynamic ip addresses or are forced to use a proxy server.

The only safe way to do it is to not save users' account information and make them re-validate on every new visit. However, if you do wish to save account information I would suggest using a salted / hashed password and a cookie whos name is an account id or something.

Just my thoughts, I'm by no means a security expert but as with any application it's a delicate balancing of security and functionality.

Brian

05.11.2008 at 09:30PM PDT, ID: 21544664

SideFX250:

Brian,

You're absolutely right, the user ID is better. But you can have a custom Session ID management scheme on the server side, negating the need even for the session id to be stored in the cookie -- or better yet having a server side mapping that accomplishes everything discussed above.

I think any attempt to save state (not requiring authentication at every visit) will result in vulnerabilities when the keys to the kingdom are on the client side. Whatever mechanism you use, it should be impossible to guess, or decrypt and hijack a session. It's XSS today, it'll be something else tomorrow.

Regarding the IP Address: The dynamic IP addresses "can" change each time a machine hits the DHCP server--but most have a lease of at least three days--usually several months. If a user has to proxy, and they're hitting your box from a different proxy each time, that's suspicious (or paranoia on the part of the user).

Ebay and numerous other large companies disallow anonymous proxies and so should you if you're dealing with credit card transactions -- I guess I'd add to your comment and say "FORCE" identity validation when the user wants to do any $$ transactions..

A corporate proxy will leave the same fingerprint every time. A series of anonymous proxies will leave a different fingerprint every time. Disallow anonymous proxies and continually changing dynamic ip addresses for saved states!

The point Ray and I are trying to make is that you fingerprint the user based on the most consistently available information that will help to identify them beyond what's stored in the cookies -- at the very least, the User Agent. You then couple those identifying attributes and hash them. I would also add the IP address -- it's generally consistent enough for the vast majority of internet users and almost always required for banning or back-tracing -- and if it isn't, force authentication.

05.11.2008 at 09:38PM PDT, ID: 21544681

SideFX250:

p.s. don't hash the password and store it client-side! At least one good reason: rainbow attacks.

Should your salt ever be figured out, the real user password could be determined--there's a domino effect.

don't hash the username! Reason: you don't need to...use an id.

What if a user uses the same username and/or the same password for several sites:

http://www.mysite.com
http://www.wellsfargo.com <---bank
http://mail.google.com <--- email account where other "forgotten" username/passwords are sent to.

05.14.2008 at 01:36PM PDT, ID: 21568433

Rank: Master

BrianGEFF719:

>>p.s. don't hash the password and store it client-side! At least one good reason: rainbow attacks.

Rainbow attacks aren't really feasible on salted hashes, if you have a 10 character salt with alphanumeric and punctuation, the rainbow table require to break the hashes would be Huge, several terabytes at least.

Also, what I used to do to avoid rainbow attacks is use a combination of different hashes...for example:

$part1 = md5($salt . $pass)
$part2 = sha1($salt_2 . $pass)

/* break md5 and sha into two different parts */
$first_half_md5 = substr($part1, 0, strlen($part1) / 2);
$second_half_md5 = substr($part1,strlen($part1)/2);
$first_half_sha = substr($part2, 0, strlen($part2) / 2);
$second_half_sha = substr($part2,strlen($part2)/2);

Now recombine it for an extra long hash:

$big_hash = $first_half_md5 . $second_half_sha . $second_half_md5 . $first_half_sha;

Such a hash with 10 character salts would be almost impossible to break with any sort of rainbow table or combination of rainbow tables for md5 and sha.

You're 100% right about using a ID, it really doesn't pose a security risk.

05.14.2008 at 01:40PM PDT, ID: 21568464

Rank: Master

BrianGEFF719:

>>Should your salt ever be figured out, the real user password could be determined--there's a domino effect.

Suppose the salt was figured out, and say that salt was: 'm0nk3y'

Now a person would have to calculate all md5 combinations of m0nk3y + password, so suppose you enforce a 6 digit password. The smallest value in the rainbow table would have length 12!

We can't live in a world where we're scared of rainbow tables and the next to impossible hash collison.

I'd love to hear other peoples thoughts on this.

05.15.2008 at 06:21AM PDT, ID: 21573259

Rank: Guru

Ray_Paseur:

@BrianGEFF719: I'll weigh in. I agree with you.

Suppose the salt contained a m0nk3y and a timestamp. Suppose we put it all behind https, and made the script sleep two seconds for every attempt. Suppose we asked for a CAPTCHA after the first failed login. And of course, we would always put the hash-generator algorithm above the web site root so it could not be found and decoded by an attacker that is spewing rainbow URLs at our site.

There are lots of ways to add incremental improvements to the security of web sites. It is reasonable to use as many as are practical, right up to the point that it starts to inconvenience legit clients.

20080236-EE-VQP-29 / EE_QW_2_20070628