Password not asked after password change [#904398]

Hi,

I have some problems:
I created a webform and wanted to grant access to a few people. One week after I wanted to grant access to te same webform to other bunch of people. My idea was to set the webform to world-fillable and control the access through the password: every week I change the password so only those can fill it, who know the actual pass.
But this failed: if I logged in previously and than change the password I don't need to write the password again.

I think this is an issue and not a normal workflow. What do You think?

Thanks,
TeeCee :o)

Comments

Comment #1

dlaidig commented 8 October 2010 at 13:38

I can agree with this. In internet explorer, if you log on to a node and don't delete your temporary internet files, every time you go that node again, even if the password is changed you will have access. This seems like a security hole to me.

Comment #2

AlexisWilke commented 15 April 2011 at 06:44

The problem is that the password acceptance was saved in the $_SESSION as TRUE. That's it.

I'm thinking to change that with a date instead. That way, when you change the password, I can save that date and if a user comes on that node and the date of the $_SESSION is too old, it breaks (i.e. you have to re-enter the password.)

Thank you.
Alexis

Comment #3

teecee commented 15 April 2011 at 07:02

Or optionally You could store the hash of the password in session and match the actual password's hash with that. In this case no need to store dates anywhere.

Thanks,
TeeCee :o)

Comment #4

AlexisWilke commented 15 April 2011 at 10:53

The hash is 40 characters (sha1) A date is 4 bytes (well, should be 8 to support time after 2068).

But there are other advantages to having a date: we can time out the password in say 2h even if the sessions time out is setup at 14 days. (There is a request in that regard!) Plus, I'd like us to be able to cancel all sessions at once. This again will work great with a time out.

As a side note: I know that the sessions are in the database in a default Drupal system. However, we cannot expect all installations to have such. There are optimizations that move sessions to memory, for example. Those would no work with SQL orders. Hence, the time and date.

Thank you for the reply.
Alexis

Comment #5

teecee commented 15 April 2011 at 11:44

I don't understand the point of the sidenote, sorry :)
Why shouldn't work the hash with the session in memory? (As far as I know session is a serialized array, so it should do nothing with SQL order.) What did I miss?

But I agree: if there are other requests, that are in the need for the datetime, than it should be used, no more words to say :)

Comment #6

AlexisWilke commented 15 April 2011 at 19:32

Hi teecee,

Good question. The module extension in regard to sessions will move the sessions to memory. That means you have access to them only via the regular session functions and not with SQL.

The following is what Core does when booting. As you can see it replaces the session commands with sess_open/close/read... Those functions are defined in ./includes/session.inc (which is why they include that file at that point.)

    case DRUPAL_BOOTSTRAP_SESSION:
      require_once variable_get('session_inc', './includes/session.inc');
      session_set_save_handler('sess_open', 'sess_close', 'sess_read', 'sess_write', 'sess_destroy_sid', 'sess_gc');
      session_start();
      break;

By default, PHP will use files to create sessions. You have one folder where you'd get thousands of files. One file represents one session. With 100 or less, it's still fast, with thousands it could get slow (although frankly with ext3 or ext4 on your hard drive, you'd still be fine.)

So... now if you look at the sess_open/close/read... functions, you'll see that the read is a SELECT * FROM {session} ... and the sess_write is an UPDATE (or INSERT INTO). This means you can search the sessions for entries such as '_protected_node' and modify them. However, if you change the session processing on your website, that would break badly. 8-}

Hope that helps clarifying. It's important for everyone to be aware of those things. I actually think that using the database for sessions slows down our server dramatically and I'll have to change that just so we can save a lot on I/O.

Thank you.
Alexis