7

I usually hang out in a community that uses a bulletin board software.

I was looking at what this software saves as cookie in my browser.

As you can see it saves 6 cookies. Amongst them, what I consider to be important for authentification are:

  1. ngisessionhash: hash of the current session
  2. ngipassword: hash (not the plain password probably) of the password
  3. ngiuserid: user's id

Those are my assumptions of course. I don't know for sure if ngilastactivity and ngilastvisit are used for the same reason.

My question is: why use all these cookie for authentication? My guess would be that maybe generating a session hash would be to easy so using the hashedpassword and userid adds security but what about cookie spoofing? I'm basically leaving on the client all fundamental informations.

What do you think?

UPDATE #1

The contents of these cookies are what I think they contains. I'm not sure about it. Of course if call a cookie ngivbpassword and contains an hash, my guess is hashedpassword. Probably it could be password+salt.

My main concern is about these solution giving to much information when under a cookie spoofing attack.

UPDATE #2 This question doesn't want to criticize the way these specific software works but, thorugh these answers I want just to learn more about securing software in a web environment.

dierre
  • 7,140
  • 12
  • 75
  • 120
  • 2
    ngivbpassword is the hash of the password?? Realy?! Thats a bad idea sending your password hash in every encrypted request... – shfx Dec 27 '10 at 15:46
  • Yep, this is mine :P cb17eee800v1361cee7985d731673c8g – dierre Dec 27 '10 at 15:47
  • @shfx: it's an hash actually. I've updated my question because maybe it wasn't clear these are my assumptions. – dierre Dec 27 '10 at 16:22
  • Apart from learning purposes, such as in this example, you should re-use an existing authentication framework whenever possible, which usually includes a *secure* "remember me" implementation. For example, take a look at https://github.com/delight-im/PHP-Auth which is both framework-agnostic and database-agnostic. – caw Oct 21 '16 at 20:52

4 Answers4

2

This happens because session and login cookies may have different lifecycles.

Imagine website with millions of users every day. The website won't store your session for a year just to log you back the next time you get back. They use login cookies for that.

These cookies are also called Remember-Me cookies.

m_vitaly
  • 11,856
  • 5
  • 47
  • 63
  • 2
    Basically what you're saying is: I check the session, if the session is expired then I check the hashed password and your userid. If they match my system will login you. – dierre Dec 27 '10 at 16:01
  • @Vitaly Polonetsky: isn't that a little unsafe? My hashed password is on my computer. – dierre Dec 27 '10 at 16:07
  • @dierr In the case you presented - yes. In general the hash will contain other information that will make guessing your password a very difficult task, for example the server could hash [username]|[password]|[other constant info about you]|[server hardcoded constant] and check hash of that. – m_vitaly Dec 27 '10 at 16:11
  • @Vitaly Polonetsky: well, it could probably be password+salt, I'm not sure. – dierre Dec 27 '10 at 16:18
  • I'm going with your answer. Basically I'm satisfied because that's probably the safest way to implement the "Remember me" feature. All considering they're giving to the client the "minimum" amount of information for doing that. Off course just using session would be less risky but that would be a limitation on functionality. – dierre Dec 27 '10 at 16:40
  • 2
    The safest way is to make the cookie completely random, restrict its path, use HTTPS and perform some server-side security checks against IP address and other parameters. – Álvaro González Dec 27 '10 at 16:45
  • @Álvaro G. Vicario : The IP check looks very good at first, but it's the most problematic restriction you can do. Most of the users have Dynamic IPs and use the same laptop from home, work or internet cafe, each time from different IP address. – m_vitaly Dec 27 '10 at 16:48
  • I agree with that. But that's HTTP ;-) – Álvaro González Dec 27 '10 at 16:49
  • @dierre holding login and password data in cookies isn't safer than holding one completely random session id. – shfx Dec 27 '10 at 16:53
  • Alvaro not everybody can afford all that. What I mean is that using HTTPS and do all the check would mean to direct more budget resources for purchasing an host that supports all that. – dierre Dec 27 '10 at 16:54
  • @shfx: in the case presented by Vitaly in which you can't save for a year a session, you need to save other information to implement a "Remember me" feature. – dierre Dec 27 '10 at 16:58
  • @dierre About memory limit while holding session data on the server e.g (160 bits + 255 bytes) * 16000000 and you got 4gigs of session data in memory for 16 000 000 users (where 160b is sha1 hash, 255B is login, ip, whatever) and it's for users logged at the same time. If you have 16m of users, you can afford 4gigs of memory ;) (Correct me if i'm wrong). – shfx Dec 27 '10 at 17:07
  • And again - chose: Security issue and less Memory VS Higher security and more memory – shfx Dec 27 '10 at 17:10
  • @shfx: software like these are dedicated to a vast type of users. Bulletin boards are used by hosts that have at most 100mb storage :D You're absolutely right but higher security means higher costs. – dierre Dec 27 '10 at 17:16
1

Sessions are not persistent. Cookies are.

Update #1: I haven't worked with vBullettin but it looks like the classical "Remember me" feature.

Update #2:

Yeah, it's a remember me feature, I'm asking why they're doing it in that way

Alright... How do you implement a "Remember me" feature? You obviously need to use cookies, I assume that's clear. Now, what do you store?

The naivest way is to store user and password in clear text and perform regular authentication. It's among the most insecure mechanisms you can use yet some sites actually do it that way.

Second slightly less naive way is to store a hash of the user and password and perform a modified version of the regular authentication. Is not as bad as the previous method but it still suffers from some issues; for instance, there's no effective way to disable or expire a saved cookie from the server.

Third way is to keep a database table with "remembered" sessions, identify each one with a long unique string and store such string in the cookie. The string can be random or calculated but, of course, randomness has the advantage that the string cannot be guessed even if you know the algorithm.

Further security can be accomplishes by storing dates, IP addresses and other piece of data in the server.

As I said, I know nothing about vBulleting but it seems they're using method 2 or method 3.

Update #3:

The contents of these cookies are what I think they contains. I'm not sure about it. Of course if call a cookie ngivbpassword and contains an hash, my guess is hashedpassword. Probably it could be password+salt.[...] My main concern is about these solution giving to much information when under a cookie spoofing attack.

A successfully cookie spoofing allows you to fully impersonate the user so you can just enter the control panel and enjoy the free buffet, thus making the cookie content irrelevant.

Whether they store a salted password or it's just a name it's something I don't know.

Álvaro González
  • 142,137
  • 41
  • 261
  • 360
  • maybe my question is not clear. I didn't ask why they use cookies in general. I've asked about the cookie configuration. Why thay use hashed session and hashed password and userid. Why all that. – dierre Dec 27 '10 at 15:22
  • Yeah, it's a remember me feature, I'm asking why they're doing it in that way. – dierre Dec 27 '10 at 15:53
  • Because they doing it wrong. You can control session TTL by setting TTL on the session cookie and session table on the server. – shfx Dec 27 '10 at 16:01
  • I've updated my answer. Every time I do so you reply that you already knew that. It'd be good to know before hand what you already know ;-) – Álvaro González Dec 27 '10 at 16:12
  • I've updated my question too so I hope now is clear what I'm looking for :) – dierre Dec 27 '10 at 16:24
  • Alvaro I'm satisfied with your question too but I can give only one correct answer. Vitaly's question was a little bit more specific on the problem. I'll try to be more clear next time :) – dierre Dec 27 '10 at 16:42
  • @Alvaro: that's what I've realized from my question. What I mean is that a software like this could manage a lot of users so the fact that they can't store a session forever needs to be solved with adding more information to implement what you called a "remember me" feature but cookie spoofing doesn't care about that. – dierre Dec 27 '10 at 17:02
  • @Alvaro: I've contacted you using your site. – dierre Dec 27 '10 at 17:20
0

Here is a question, what are your concerns? Are you building some kind of authentication system? I also think that having the user id and password in cookies can be a security issue. is user id encoded or an integer?

Pablo
  • 5,897
  • 7
  • 34
  • 51
  • 1
    just an integer. No I'm not building one. But I'm getting my master in computer engineering and I've spent part of last semester in learning security issue so it was a natural question for me to understand why vB is "overusing" cookies to handle authentication. – dierre Dec 27 '10 at 15:56
  • First, i have no clue how is vB using this cookies. I would love to further discuss this topi as its of my best interest but i am on my phone. I have an open source PHP user authentication class project called uFlex on where i used built in encoders to create a single hash for autologin with the password hash and an encode user id. – Pablo Dec 27 '10 at 16:11
0

  • Cookies should be as-small-as-they-can peace of information about who you are on the server.

  • Sessionhash, session_id or sid is unique ID of you (your session on the server). The rest of cookies can be easily hidden on the server side.

  • Holding password hash in cookies is a security issue. You should avoid that.

  • Last 4 cookies comes from google ads.

PS. Most bulletin boards are not so great software anyway.

shfx
  • 1,261
  • 1
  • 11
  • 16
  • I've updated my question. I explained better the hashed password thing. I was using hashed to express encrypted but it was not clear. – dierre Dec 27 '10 at 16:45
  • @dierre Encryption is indeed not the same thing as hashing, but you figured that out. How did that Master's go anyway? Sorry for 2 and a half year later answer, just rambled into this interesting discussion :) – Jonast92 Aug 02 '13 at 10:19