Author Topic: Site updater script  (Read 6606 times)

0 Members and 1 Guest are viewing this topic.

Offline Siege

  • Full Member
  • ***
  • Male
  • Posts: 210
    • Siege's Snippets
Site updater script
« on: May 30, 2008, 02:05:32 pm »
I'm trying to develop a reasonably secure site updater. Here's what I've come up with so far:

The script presents a login form using POST via https. It will not login except via https and POST, discarding any data from invalid attempts. All login attempts, valid and invalid, are recorded to a file listing date/time, IP, and whether the login succeeded.

Once it accepts the password, the script hashes said password, then compares the hash to a previously-created file named "hash.dat". If the values are the same, it then sets a secure cookie (which the browser will only pass to the server over a secure connection) containing a hash of the password hash + current date, set to expire on browser close.

So long as the cookie is present and valid when compared to a hash of hash.dat + current date, the updater will stay logged in. This means the script will require the user to re-login the next day even if the cookie is still present. I may change this limit to half an hour or less, without regard to user activity.

On logout, the cookie is cleared by replacing its contents with "expired" and letting it expire on close.

User changes the password by creating a new hash.dat and uploading it to the server.

Does this sound good, or are there concerns I still need to address (aside from secure ftp of the hash file, and properly guarding my site password)?
Dragons have treasure better than gold.

"If code can be speech, then software can be art."

Visit WikiFur, the furry encyclopedia! Alternatively, Visit Siege's Snippets!

Offline Richard K Niner

  • Sr. Member
  • Indecision incarnate canine
  • ****
  • Male
  • Posts: 341
    • K9 Unit
Re: Site updater script
« Reply #1 on: May 30, 2008, 05:45:40 pm »
Needs more salt.

I'm also not incredibly comfortable with using the date for timing things out in said cookie: what happens if you log in at 11:59 pm server time?
« Last Edit: May 30, 2008, 05:50:04 pm by Richard K Niner »

Offline Siege

  • Full Member
  • ***
  • Male
  • Posts: 210
    • Siege's Snippets
Re: Site updater script
« Reply #2 on: May 30, 2008, 07:37:20 pm »
What sort of extra salt would you recommend, and where should I apply it? On the hash file or the cookie?

As for date-based timeout, if I did go to something more fine-grained like a half hour, then I'd need to use a time diff anyway. But thanks for bringing that up.
Dragons have treasure better than gold.

"If code can be speech, then software can be art."

Visit WikiFur, the furry encyclopedia! Alternatively, Visit Siege's Snippets!

Offline Richard K Niner

  • Sr. Member
  • Indecision incarnate canine
  • ****
  • Male
  • Posts: 341
    • K9 Unit
Re: Site updater script
« Reply #3 on: May 30, 2008, 11:11:25 pm »
It's more important for the cookie (session hijacking), but having it on the password file reduces the chance of being able to guess it from the hash (in the event that it becomes weak enough to do so some time in the future).

Offline Siege

  • Full Member
  • ***
  • Male
  • Posts: 210
    • Siege's Snippets
Re: Site updater script
« Reply #4 on: May 31, 2008, 11:48:05 am »
I think the biggest problem with adding salt to the base hash is that I'll need to add it to the cookie, which means it must be available to the updater script. If someone compromises my account, they can easily ftp the script and see what that salt is. On the other hand, I could just use one of the other files in the account (let's say this one), and by flipping a single bit create a new salt. On the gripping hand, I could use a pre-hashed value hard-coded into the script and just update the script when I change the salt.

By keeping the protected files up to date, and by regularly using new salt, I should be able to avoid those problems. Which means the two weakest points of failure would be using an unprotected means of transferring files to the account, or by using a weak password for my account (or an insecure means of changing it).

I'd better guard my email, but I'll have to assume that any cleartext has been intercepted by someone (a few TLAs come to mind).

Ah, well.

I guess this is why security professionals get paranoid sometimes.

I need to learn more about using salt, I guess. Like how other algorithms use it.
« Last Edit: May 31, 2008, 11:56:14 am by Siege »
Dragons have treasure better than gold.

"If code can be speech, then software can be art."

Visit WikiFur, the furry encyclopedia! Alternatively, Visit Siege's Snippets!

Offline Richard K Niner

  • Sr. Member
  • Indecision incarnate canine
  • ****
  • Male
  • Posts: 341
    • K9 Unit
Re: Site updater script
« Reply #5 on: May 31, 2008, 06:19:49 pm »
Salt's really at its most useful when you make it hard to predict.  For instance, have the server pick one randomly, and store it in a file with how old it is.  After 24 hours, consider it stale and generate more salt.

Note that if the salt is then a date, you've pretty much got the system you originally described.

Offline Siege

  • Full Member
  • ***
  • Male
  • Posts: 210
    • Siege's Snippets
Re: Site updater script
« Reply #6 on: May 31, 2008, 06:39:02 pm »
Okay, based on your suggetions, here's the algorithm I have so far.

0. Login security:
  A. Presents login form with POST via https. Will not login except via https and POST, discarding URI data from invalid attempts.
  B. Once it accepts the password, the script hashes said password, then compares the hash to a previously-created file named "hash.dat". If the values are the same:
    i. A file "salt.dat" is generated (or salt info is added to hash.dat), using a hash of the current time or some random value. File contents are [salt, generation time].
    ii. The script then sets a secure cookie (which the browser will only pass to the server over a secure connection) containing a hash of the password hash + salt, set to expire on browser close.
  C. All login attempts, valid and invalid, are recorded to a file listing date/time, IP, whether the login succeeded, and why it failed.
  D. So long as the salt is less than half an hour old, and the cookie is present and valid when compared to a hash of hash.dat + salt, the updater will stay logged in.

3. Logout: The script clears the salt file by setting its contents to [0, 0], then clears the cookie by changing its contents to "expired" and setting its expiry to now.
Dragons have treasure better than gold.

"If code can be speech, then software can be art."

Visit WikiFur, the furry encyclopedia! Alternatively, Visit Siege's Snippets!

Offline Richard K Niner

  • Sr. Member
  • Indecision incarnate canine
  • ****
  • Male
  • Posts: 341
    • K9 Unit
Re: Site updater script
« Reply #7 on: June 01, 2008, 08:24:12 am »
Also, it may be a good idea, despite the performance penalty, to put the login form on a secured page.  This helps prevent Mallory from learning your password.

Offline Siege

  • Full Member
  • ***
  • Male
  • Posts: 210
    • Siege's Snippets
Re: Site updater script
« Reply #8 on: June 01, 2008, 10:01:46 am »
So long as the transaction occurs over a secure connection, it's not really necessary to start by loading the form in https; that's a sop to people who want the visibility of it. But yes, all transactions from login through logout should occur over a secure connection, and any insecure transaction should be cause for suspicion (and recorded as such).

This is enforced by using a secure cookie, which as I said before will only be passed to the server over a secure connection (thank you Security Now episodes 113 and 115).

I should probably record successful logouts in the log file. I'm also going to have to look up file locking in php, so concurrent attempts don't intermix or overwrite each other's log entries.
Dragons have treasure better than gold.

"If code can be speech, then software can be art."

Visit WikiFur, the furry encyclopedia! Alternatively, Visit Siege's Snippets!

Offline Richard K Niner

  • Sr. Member
  • Indecision incarnate canine
  • ****
  • Male
  • Posts: 341
    • K9 Unit
Re: Site updater script
« Reply #9 on: June 01, 2008, 05:51:29 pm »
Technically, it's not necessary to load the form over a secure connection, but doing so ensures that it hasn't been modified in transit; pointing the form to a different server might not be noticeable until you've already sent the credentials (unless you actually check the page source every time)