Rails - Jan 2006 - Generating a long, unique "ticket" number.

Hello --

I would like to setup a system where a user can generate a "ticket". 
This ticket will be stored indefinitely.  The ticket will be sent to 
someone who does not have an account on the system and therefore, I 
would like to ensure some level of security in that ticket number.

Basically, the other user would receive an email like:

---
Please click on the link below to view this ticket:

http://somehost.somedomain.com/showticket/Ajeif3094JlejdejIWDNei23094jfe4
----

The stuff at the end would, therefore, be the unique ticket hash.  The 
system is otherwise secure and there is very little motivation to 
reverse engineer the ticket number.

I do, however, need to assure uniqueness in the ticket number among 
several hundred/thousand users that will be submitting these, so they 
can''t just be random.  It will also be stored indefinitely.

Since the ticket number will be a key in a database table, I think it 
could be generated as a one-way hash of the date and some other 
information.

Can someone suggest a good way to create this?

   Jake

-- 
Posted via http://www.ruby-forum.com/.

How about a hash of the unique id in the database table with some salt mixed
in.  That would be guaranteed to be unique.

If I understand what you are doing, you''d have to store that hash in
your
table so that you can search on it.  Make sure you make it an indexed field,
so those searches go quickly.

matt

On 1/20/06, Jake Janovetz <jakejanovetz@yahoo.com>
wrote:
>
> Hello --
>
> I would like to setup a system where a user can generate a
"ticket".
> This ticket will be stored indefinitely.  The ticket will be sent to
> someone who does not have an account on the system and therefore, I
> would like to ensure some level of security in that ticket number.
>
> Basically, the other user would receive an email like:
>
> ---
> Please click on the link below to view this ticket:
>
> http://somehost.somedomain.com/showticket/Ajeif3094JlejdejIWDNei23094jfe4
> ----
>
> The stuff at the end would, therefore, be the unique ticket hash.  The
> system is otherwise secure and there is very little motivation to
> reverse engineer the ticket number.
>
> I do, however, need to assure uniqueness in the ticket number among
> several hundred/thousand users that will be submitting these, so they
> can''t just be random.  It will also be stored indefinitely.
>
> Since the ticket number will be a key in a database table, I think it
> could be generated as a one-way hash of the date and some other
> information.
>
> Can someone suggest a good way to create this?
>
>    Jake
>
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060120/1488955b/attachment.html

Jake,

What about using
http://wiki.rubyonrails.org/rails/pages/Uses+Guid+Plugin in your
ticket model?


Cody


On 1/20/06, matthew clark <winescout@gmail.com>
wrote:
> How about a hash of the unique id in the database table with some salt
mixed
> in.  That would be guaranteed to be unique.
>
>  If I understand what you are doing, you''d have to store that hash
in your
> table so that you can search on it.  Make sure you make it an indexed
field,
> so those searches go quickly.
>
>  matt
>
>
> On 1/20/06, Jake Janovetz <jakejanovetz@yahoo.com> wrote:
> > Hello --
> >
> > I would like to setup a system where a user can generate a
"ticket".
> > This ticket will be stored indefinitely.  The ticket will be sent to
> > someone who does not have an account on the system and therefore, I
> > would like to ensure some level of security in that ticket number.
> >
> > Basically, the other user would receive an email like:
> >
> > ---
> > Please click on the link below to view this ticket:
> >
> >
> http://somehost.somedomain.com/showticket/Ajeif3094JlejdejIWDNei23094jfe4
> > ----
> >
> > The stuff at the end would, therefore, be the unique ticket hash.  The
> > system is otherwise secure and there is very little motivation to
> > reverse engineer the ticket number.
> >
> > I do, however, need to assure uniqueness in the ticket number among
> > several hundred/thousand users that will be submitting these, so they
> > can''t just be random.  It will also be stored indefinitely.
> >
> > Since the ticket number will be a key in a database table, I think it
> > could be generated as a one-way hash of the date and some other
> > information.
> >
> > Can someone suggest a good way to create this?
> >
> >    Jake
> >
> > --
> > Posted via http://www.ruby-forum.com/.
> > _______________________________________________
> > Rails mailing list
> > Rails@lists.rubyonrails.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails
> >
>
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
>
>

--
http://www.codyfauser.com

matthew clark wrote:
> How about a hash of the unique id in the database table with some salt 
> mixed
> in.  That would be guaranteed to be unique.
> 
> If I understand what you are doing, you''d have to store that hash
in
> your
> table so that you can search on it.  Make sure you make it an indexed 
> field,
> so those searches go quickly.
> 
> matt
This is exactly what I had in mind.  Problem is, I''ve only heard those 
terms and really don''t know the implications of "mixing in
salt".  I''ll
do some Googling, but if you have any references, they would be helpful.

   Jake

-- 
Posted via http://www.ruby-forum.com/.

Cody Fauser wrote:
> Jake,
> 
> What about using
> http://wiki.rubyonrails.org/rails/pages/Uses+Guid+Plugin in your
> ticket model?
> 
Thanks, Cody.  The doc doesn''t say much on how to really use it, but 
I''ll take a look at the source and see what I can gleen!

   Cheers,
   Jake

-- 
Posted via http://www.ruby-forum.com/.

You hash a string.  Salt is just any extra string you want to add to the id,
so -

unique_id.to_s + "Some salt"

and then hashing that value would be "mixing in salt"

The purpose of the salt is to prevent people from guessing your hashing
scheme.  If you just used just the id, for instance, someone could guess
that, hash the number 56, and get access to your system under ticket 56.

matt

On 1/20/06, Jake Janovetz <jakejanovetz@yahoo.com>
wrote:
>
> matthew clark wrote:
> > How about a hash of the unique id in the database table with some salt
> > mixed
> > in.  That would be guaranteed to be unique.
> >
> > If I understand what you are doing, you''d have to store that
hash in
> > your
> > table so that you can search on it.  Make sure you make it an indexed
> > field,
> > so those searches go quickly.
> >
> > matt
>
> This is exactly what I had in mind.  Problem is, I''ve only heard
those
> terms and really don''t know the implications of "mixing in
salt".  I''ll
> do some Googling, but if you have any references, they would be helpful.
>
>    Jake
>
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060120/ac4f0025/attachment.html

matthew clark wrote:
> You hash a string.  Salt is just any extra string you want to add to the 
> id,
> so -
> 
> unique_id.to_s + "Some salt"
> 
> and then hashing that value would be "mixing in salt"
> 
> The purpose of the salt is to prevent people from guessing your hashing
> scheme.  If you just used just the id, for instance, someone could guess
> that, hash the number 56, and get access to your system under ticket 56.
> 
> matt
class User < ActiveRecord::Base
   @@salt = ''SOMETHING_SECRET_COMES_HERE''
   cattr_accessor :salt

   def self.sha1(pass)
     Digest::SHA1.hexdigest("#{salt}--#{pass}--")
   end

end

This is what I use in my user model.

Pretty straightforward isnt it?

Gokhan Arli
Web Developer
www.sylow.net

-- 
Posted via http://www.ruby-forum.com/.

Creating a hash based on the current time should be sufficient:

require ''digest/sha1''
Digest::SHA1.hexdigest("#{Time.now.to_f}")

-Jonny.

Jake Janovetz wrote:
> Hello --
> 
> I would like to setup a system where a user can generate a
"ticket".
> This ticket will be stored indefinitely.  The ticket will be sent to 
> someone who does not have an account on the system and therefore, I 
> would like to ensure some level of security in that ticket number.
> 
> Basically, the other user would receive an email like:
> 
> ---
> Please click on the link below to view this ticket:
> 
> http://somehost.somedomain.com/showticket/Ajeif3094JlejdejIWDNei23094jfe4
> ----
> 
> The stuff at the end would, therefore, be the unique ticket hash.  The 
> system is otherwise secure and there is very little motivation to 
> reverse engineer the ticket number.
> 
> I do, however, need to assure uniqueness in the ticket number among 
> several hundred/thousand users that will be submitting these, so they 
> can''t just be random.  It will also be stored indefinitely.
> 
> Since the ticket number will be a key in a database table, I think it 
> could be generated as a one-way hash of the date and some other 
> information.
> 
> Can someone suggest a good way to create this?
> 
>    Jake

-- 
Posted via http://www.ruby-forum.com/.

I was just reading an article about accounts getting compromised at
Live Journal by using cross site scripting to steal the session hash
keys.

Does it add security to associate the session hash key with an IP? Or
does that cause additional problems?

--
Jon Smirl
jonsmirl@gmail.com

Jon Smirl wrote:
> I was just reading an article about accounts getting compromised at
> Live Journal by using cross site scripting to steal the session hash
> keys.
> 
> Does it add security to associate the session hash key with an IP? Or
> does that cause additional problems?
> 
> --
> Jon Smirl
> jonsmirl@gmail.com
Yes it helps.  The only minor inconvenience occurs when laptop users go 
home at night and try to reconnect from home.  They would have to log in 
again.

_Kevin

-- 
Posted via http://www.ruby-forum.com/.

Jonathan Viney wrote:
> Creating a hash based on the current time should be sufficient:
> 
> require ''digest/sha1''
> Digest::SHA1.hexdigest("#{Time.now.to_f}")
> 
> -Jonny.
> 
> Jake Janovetz wrote:
>> Hello --
>> 
>> I would like to setup a system where a user can generate a
"ticket".
>> This ticket will be stored indefinitely.  The ticket will be sent to 
>> someone who does not have an account on the system and therefore, I 
>> would like to ensure some level of security in that ticket number.

Thanks Jonny-

I ended up doing:

    Digest::SHA1.hexdigest("#{Time.now.to_f}#{rand}")

Occasionally, the Time.now.to_f will turn up the same number on two 
consecutive calls.  Apparently the resolution isn''t high enough.  The 
rand helps guard against that a bit.

   Jake

-- 
Posted via http://www.ruby-forum.com/.