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:
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
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
Jake,
What about using
http://wiki.rubyonrails.org/rails/pages/Uses+Guid+Plugin in your
ticket model?
Cody
On 1/20/06, matthew clark [email protected] wrote:
On 1/20/06, Jake J. [email protected] wrote:
Please click on the link below to view this ticket:
several hundred/thousand users that will be submitting these, so they
[email protected]
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
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
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 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
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:
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. 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.
[email protected]
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
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
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.
[email protected]