Make sure you use some salt, though.
On Mon, May 19, 2008 at 1:40 AM, Martin Makundi
[EMAIL PROTECTED] wrote:
If you use hash you do not need to store the random part into the
db. Saves you some persistence trouble.
2008/5/19 Michael Allan [EMAIL PROTECTED]:
Sam Stainsby wrote:
Martin
You must be either storing the hash, or the data that you are hashing to
regenerate the hash.
On Mon, 19 May 2008 08:40:36 +0300, Martin Makundi wrote:
If you use hash you do not need to store the random part into the db.
Saves you some persistence trouble.
2008/5/19 Michael Allan [EMAIL
Sam Stainsby wrote:
Martin Makundi wrote:
The benefit in digest is that the user (or another user) cannot
fabricate it... so easily.
Just send a large random number ... no need for expensive hash
operations.
But use java.security.SecureRandom, not java.util.Random.
--
Michael Allan
If you use hash you do not need to store the random part into the
db. Saves you some persistence trouble.
2008/5/19 Michael Allan [EMAIL PROTECTED]:
Sam Stainsby wrote:
Martin Makundi wrote:
The benefit in digest is that the user (or another user) cannot
fabricate it... so easily.
Just
You may also want to have a enum/int to represent what kind of token it is.
New user, new email, forgot password, etc..
To have a field in the user-account table to store this value? Or do you
mean to send this as part of the activation URL?
And what is the purpose to have this?
On Thu, May
What is the advantage of using message digest over uuid? Isn't message
digest not guaranteed to be unique where as UUID is always unique?
On Thu, May 15, 2008 at 7:39 PM, Martin Makundi
[EMAIL PROTECTED] wrote:
You could also just use a md5 hashkey with content specific to the account:
The benefit in digest is that the user (or another user) cannot
fabricate it... so easily.
**
Martin
2008/5/16 Matthew Young [EMAIL PROTECTED]:
What is the advantage of using message digest over uuid? Isn't message
digest not guaranteed to be unique where as UUID is always unique?
On Thu,
. Is this how it's done?
Thanks for any help!
--
View this message in context:
http://www.nabble.com/Account-Activation-Email-generation-and-response-processing%3A-any-design-example--tp17264315p17281858.html
Sent from the Wicket - User mailing list archive at Nabble.com
On Fri, 16 May 2008 21:15:34 +0300, Martin Makundi wrote:
The benefit in digest is that the user (or another user) cannot
fabricate it... so easily.
Just send a large random number that is unique on the server. Keep a copy
and compare with what the recipient sends back. Simple - no need for
I need to implement the usual account activation via email function. Can
anyone point me to some example of how this is implemented? If in Wicket
even better but anything would help me a lot.
One question I have is how to generate hard to guess unique keys in the
email link? I use Hibernate
java.util.UUID.randomUUID().toString()
On Thu, May 15, 2008 at 6:57 PM, Matthew Young [EMAIL PROTECTED] wrote:
I need to implement the usual account activation via email function. Can
anyone point me to some example of how this is implemented? If in Wicket
even better but anything would help
You may also want to have a enum/int to represent what kind of token it is.
New user, new email, forgot password, etc..
On Thu, May 15, 2008 at 7:01 PM, James Carman [EMAIL PROTECTED]
wrote:
java.util.UUID.randomUUID().toString()
On Thu, May 15, 2008 at 6:57 PM, Matthew Young [EMAIL
You could also just use a md5 hashkey with content specific to the account:
MessageDigest messageDigest = MessageDigest.getInstance(MD5);
return new String(messageDigest.digest((encryptionKey +
value).getBytes()));
**
Martin
2008/5/16 Ryan Gravener [EMAIL PROTECTED]:
You may
13 matches
Mail list logo
