From: Rich Kilmer <rich@...>
Date: 2002-02-14T14:19:05+09:00
Subject: RE: IOWA troubles (was Re: choice of HTML templating system)

> My god, you're right... I can't believe I actually advocated frames...
> where's that soap, I feel dirty! :)  Actually, I didn't really
> *advocate* it, just pointed out that you could do it if you cared about
> the URI's :)
>
> I notice I deleted your comment about security which I meant to reply
> to.  I agree this is a problem.  We intend to add support for
> authentication which would help a little (for expired sessions, etc),
> and not showing the session-id in the URI (ie. putting it in a cookie)
> also helps at some level.  We've also thought about storing the IP
> address of the user and only allowing connections to their session from
> that IP.  Obviously all these items have pros and cons and need to be
> configurable.  If you have any other ideas that would help please
> mention them. We haven't really adressed this yet but we should.
>
> In closing, I should reiterate that Iowa is great for designing web
> *applications* but not so great for desiging web *sites*.  I keep
> thinking we should be writing our web site using Iowa as a proof of
> concept, but I don't think it works very well - for the exact reason
> that you want to be able to bookmark it... it isn't really an
> application, just a bunch of static, or quasi-dynamic content.
>
> Phew, long message, hope it clarifies some,
>
> Julian
>
> --
> julian@beta4.com
> Beta4 Productions (http://www.beta4.com)

On a project I was on we created a session token that consisted of this:

<time in millis>_<random data>_<sha1 hash of time:random:server_key>

The point is when a user authenticates, you generate this as the session key
that contains the current time which you can use to expire the session.
This creates a completely standalone token which times itself out.  Each
time a user accesses with a valid token you regenerate a new (valid) token
(keeping the session alive).  Obviously, the tokens become useless once the
timout period has expired and if anyone screws with the time aspect of the
token the SHA1 hash invalidates.

Here is some code that (re)implements it:

require 'digest/sha1'

include Digest

@server_key = "secret"
@timeout = 2 # seconds

def get_salt(size=16)
 salt = ""
 size.times {|i| salt << sprintf('%02x', rand(16))}
 salt
end

def make_token
 t = Time.new
 time = t.to_i.to_s+"."+t.usec.to_s
 salt = get_salt(8)
 hash = SHA1.new("#{time}:#{salt}:#{@server_key}").hexdigest
 token = "#{time}_#{salt}_#{hash}"
end

def token_valid?(token)
 t = Time.new
 time = t.to_i.to_s+"."+t.usec.to_s
 token.scan(/(.*)_(.*)_(.*)/) do |t_time, t_salt, t_hash|
  valid_hash = SHA1.new("#{t_time}:#{t_salt}:#{@server_key}").hexdigest
  return (t_hash == valid_hash) && (time.to_f - t_time.to_f < @timeout)
 end
 false
end

t = make_token
sleep 1
puts token_valid?(t) #=> true

sleep 3
puts token_valid?(t) #=> false ... timeout