Forum: Ruby on Rails Generating a long, unique "ticket" number.

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Jake J. (Guest)
on 2006-01-20 19:07
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/Ajeif309...
----

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
matthew clark (Guest)
on 2006-01-20 19:17
(Received via mailing list)
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
Cody F. (Guest)
on 2006-01-20 19:26
(Received via mailing list)
Jake,

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


Cody


On 1/20/06, matthew clark <removed_email_address@domain.invalid> wrote:
> On 1/20/06, Jake J. <removed_email_address@domain.invalid> wrote:
> > Please click on the link below to view this ticket:
> > several hundred/thousand users that will be submitting these, so they
> > --
> removed_email_address@domain.invalid
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
>
>


--
http://www.codyfauser.com
Jake J. (Guest)
on 2006-01-21 00:35
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
Jake J. (Guest)
on 2006-01-21 00:36
Cody F. 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
matthew clark (Guest)
on 2006-01-21 00:50
(Received via mailing list)
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
Gokhan A. (Guest)
on 2006-01-21 01:52
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 A.
Web D.
www.sylow.net
Jonathan V. (Guest)
on 2006-01-21 04:00
Creating a hash based on the current time should be sufficient:

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

-Jonny.

Jake J. 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/Ajeif309...
> ----
>
> 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
Jon S. (Guest)
on 2006-01-21 04:03
(Received via mailing list)
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 S.
removed_email_address@domain.invalid
Kevin O. (Guest)
on 2006-01-21 04:06
Jon S. 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 S.
> removed_email_address@domain.invalid

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
Jake J. (Guest)
on 2006-01-24 02:14
Jonathan V. wrote:
> Creating a hash based on the current time should be sufficient:
>
> require 'digest/sha1'
> Digest::SHA1.hexdigest("#{Time.now.to_f}")
>
> -Jonny.
>
> Jake J. 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
This topic is locked and can not be replied to.