Re: Encrypt Form Fields Using JS

2010-08-06 Thread MZemeck
I should make it clear, the intention is to use SSL and JS one-way hash, 
not just JS...




Jeremy Thomerson  
08/03/2010 03:49 PM
Please respond to
users@wicket.apache.org


To
users@wicket.apache.org
cc

Subject
Re: Encrypt Form Fields Using JS






On Tue, Aug 3, 2010 at 1:24 PM,  wrote:

> I have to laugh because I also agree its kind of crazy...
>
> Yes the original value must be hashed by the client.  The reasoning 
being
> that SSL could be broken and expose the data.  I don't necessarily agree
> but thats how the original system was written.
>

Client side JavaScript can certainly be broken *MUCH* easier than SSL.
 Perhaps the following reference [1] will help you resolve this situation 
:)

1 -
http://jobsearch.monster.com/PowerSearch.aspx?tjt=Programmer&where=New%20York



-- 
Jeremy Thomerson
http://www.wickettraining.com





Notice: This communication, including any attachments, is intended solely 
for the use of the individual or entity to which it is addressed. This 
communication may contain information that is protected from disclosure 
under State and/or Federal law. Please notify the sender immediately if 
you have received this communication in error and delete this email from 
your system. If you are not the intended recipient, you are requested not 
to disclose, copy, distribute or take any action in reliance on the 
contents of this information.

Re: Encrypt Form Fields Using JS

2010-08-03 Thread Jeremy Thomerson
On Tue, Aug 3, 2010 at 1:24 PM,  wrote:

> I have to laugh because I also agree its kind of crazy...
>
> Yes the original value must be hashed by the client.  The reasoning being
> that SSL could be broken and expose the data.  I don't necessarily agree
> but thats how the original system was written.
>

Client side JavaScript can certainly be broken *MUCH* easier than SSL.
 Perhaps the following reference [1] will help you resolve this situation :)

1 -
http://jobsearch.monster.com/PowerSearch.aspx?tjt=Programmer&where=New%20York


-- 
Jeremy Thomerson
http://www.wickettraining.com


Re: Encrypt Form Fields Using JS

2010-08-03 Thread James Carman
They also understand that the one-way hashes aren't unique, right?  Two
values may hash (or, more accurately, message digest) to the same value, but
that doesn't mean they're equal.

On Tue, Aug 3, 2010 at 2:24 PM,  wrote:

> I have to laugh because I also agree its kind of crazy...
>
> Yes the original value must be hashed by the client.  The reasoning being
> that SSL could be broken and expose the data.  I don't necessarily agree
> but thats how the original system was written.
>
>
>
>
> James Carman 
> Sent by: jcar...@carmanconsulting.com
> 08/03/2010 02:19 PM
> Please respond to
> users@wicket.apache.org
>
>
> To
> users@wicket.apache.org
> cc
>
> Subject
> Re: Encrypt Form Fields Using JS
>
>
>
>
>
>
> And, you don't want to convert it before you store it in the db?  It must
> be
> converted at the browser level?  Is there any more information you can
> give
> us that would make this requirement not sound so crazy? :)
>
> On Tue, Aug 3, 2010 at 2:15 PM,  wrote:
>
> > Correct
> >
> >
> >
> >
> > James Carman 
> > Sent by: jcar...@carmanconsulting.com
> > 08/03/2010 02:12 PM
> > Please respond to
> > users@wicket.apache.org
> >
> >
> > To
> > users@wicket.apache.org
> > cc
> >
> > Subject
> > Re: Encrypt Form Fields Using JS
> >
> >
> >
> >
> >
> >
> > So, you never need to get the original values out of the database?
> >
> > On Tue, Aug 3, 2010 at 2:10 PM,  wrote:
> >
> > > An already existing system is being rewritten and the db currently
> > stores
> > > hashed values.  I don't disagree there are better ways to reach the
> end
> > > goal, but this is the spec I am working with.
> > >
> > >
> > >
> > >
> > > James Carman 
> > > Sent by: jcar...@carmanconsulting.com
> > > 08/03/2010 01:45 PM
> > > Please respond to
> > > users@wicket.apache.org
> > >
> > >
> > > To
> > > users@wicket.apache.org
> > > cc
> > >
> > > Subject
> > > Re: Encrypt Form Fields Using JS
> > >
> > >
> > >
> > >
> > >
> > >
> > > And, what does that buy you?  Why do you want to submit one-way hashed
> > > values?
> > >
> > > On Tue, Aug 3, 2010 at 1:37 PM,  wrote:
> > >
> > > > Ok, the value will be hashed, one-way...anyone have any ideas?
> > > >
> > > >
> > > >
> > > >
> > > > James Carman 
> > > > Sent by: jcar...@carmanconsulting.com
> > > > 08/02/2010 04:42 PM
> > > > Please respond to
> > > > users@wicket.apache.org
> > > >
> > > >
> > > > To
> > > > users@wicket.apache.org
> > > > cc
> > > >
> > > > Subject
> > > > Re: Encrypt Form Fields Using JS
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Then it's not "encryption".  Encrypted data should be readable to
> > those
> > > > who
> > > > have the "key."
> > > >
> > > > On Mon, Aug 2, 2010 at 3:29 PM,  wrote:
> > > >
> > > > > Thanks for the reply, that would work however per our business
> rules
> > > the
> > > > > encryption must be one-way and will not be decrypted...
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Igor Vaynberg 
> > > > > 08/02/2010 03:23 PM
> > > > > Please respond to
> > > > > users@wicket.apache.org
> > > > >
> > > > >
> > > > > To
> > > > > users@wicket.apache.org
> > > > > cc
> > > > >
> > > > > Subject
> > > > > Re: Encrypt Form Fields Using JS
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > override getinputasarray() on the field and decrypt it there, that
> > way
> > > > > wicket sees the decrypted value
> > > > >
> > > > > -igor
> > > > >
> > > > > On Mon, Aug 2, 2010 at 12:14 PM,   wrote:
> > > > > > I totally agree, seems like double-duty that accomplis

RE: Encrypt Form Fields Using JS

2010-08-03 Thread Jeffrey Schneller
Can you create the text field and a hidden text field and have some
javascript that validates as the user types or an update link next to
the field?  Once the entire SSN is entered or the link is pressed then
hash the ssn and store in the hidden text field.  Once hashed, overwrite
the value in the visible text field with "###-##-" and disable the
text entry.  You could even leave the text entry enabled and have the
client-side validator check if the field contains "###-##-" and
don't perform the re-hash.  Don't do the validation through wicket
validators.  There are plenty of jquery or standalone javascript ssn
validators out there.





-Original Message-
From: mzem...@osc.state.ny.us [mailto:mzem...@osc.state.ny.us] 
Sent: Tuesday, August 03, 2010 2:24 PM
To: users@wicket.apache.org
Subject: Re: Encrypt Form Fields Using JS

I have to laugh because I also agree its kind of crazy...

Yes the original value must be hashed by the client.  The reasoning
being 
that SSL could be broken and expose the data.  I don't necessarily agree

but thats how the original system was written.




James Carman  
Sent by: jcar...@carmanconsulting.com
08/03/2010 02:19 PM
Please respond to
users@wicket.apache.org


To
users@wicket.apache.org
cc

Subject
Re: Encrypt Form Fields Using JS






And, you don't want to convert it before you store it in the db?  It
must 
be
converted at the browser level?  Is there any more information you can 
give
us that would make this requirement not sound so crazy? :)

On Tue, Aug 3, 2010 at 2:15 PM,  wrote:

> Correct
>
>
>
>
> James Carman 
> Sent by: jcar...@carmanconsulting.com
> 08/03/2010 02:12 PM
> Please respond to
> users@wicket.apache.org
>
>
> To
> users@wicket.apache.org
> cc
>
> Subject
> Re: Encrypt Form Fields Using JS
>
>
>
>
>
>
> So, you never need to get the original values out of the database?
>
> On Tue, Aug 3, 2010 at 2:10 PM,  wrote:
>
> > An already existing system is being rewritten and the db currently
> stores
> > hashed values.  I don't disagree there are better ways to reach the 
end
> > goal, but this is the spec I am working with.
> >
> >
> >
> >
> > James Carman 
> > Sent by: jcar...@carmanconsulting.com
> > 08/03/2010 01:45 PM
> > Please respond to
> > users@wicket.apache.org
> >
> >
> > To
> > users@wicket.apache.org
> > cc
> >
> > Subject
> > Re: Encrypt Form Fields Using JS
> >
> >
> >
> >
> >
> >
> > And, what does that buy you?  Why do you want to submit one-way
hashed
> > values?
> >
> > On Tue, Aug 3, 2010 at 1:37 PM,  wrote:
> >
> > > Ok, the value will be hashed, one-way...anyone have any ideas?
> > >
> > >
> > >
> > >
> > > James Carman 
> > > Sent by: jcar...@carmanconsulting.com
> > > 08/02/2010 04:42 PM
> > > Please respond to
> > > users@wicket.apache.org
> > >
> > >
> > > To
> > > users@wicket.apache.org
> > > cc
> > >
> > > Subject
> > > Re: Encrypt Form Fields Using JS
> > >
> > >
> > >
> > >
> > >
> > >
> > > Then it's not "encryption".  Encrypted data should be readable to
> those
> > > who
> > > have the "key."
> > >
> > > On Mon, Aug 2, 2010 at 3:29 PM,  wrote:
> > >
> > > > Thanks for the reply, that would work however per our business 
rules
> > the
> > > > encryption must be one-way and will not be decrypted...
> > > >
> > > >
> > > >
> > > >
> > > > Igor Vaynberg 
> > > > 08/02/2010 03:23 PM
> > > > Please respond to
> > > > users@wicket.apache.org
> > > >
> > > >
> > > > To
> > > > users@wicket.apache.org
> > > > cc
> > > >
> > > > Subject
> > > > Re: Encrypt Form Fields Using JS
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > override getinputasarray() on the field and decrypt it there,
that
> way
> > > > wicket sees the decrypted value
> > > >
> > > > -igor
> > > >
> > > > On Mon, Aug 2, 2010 at 12:14 PM,  
wrote:
> > > > > I totally agree, seems like double-duty that accomplishes very
> > little,
> > > > and
> > > > > actually adds overhead.  But this is another debate and the
> feature
&g

Re: Encrypt Form Fields Using JS

2010-08-03 Thread MZemeck
I have to laugh because I also agree its kind of crazy...

Yes the original value must be hashed by the client.  The reasoning being 
that SSL could be broken and expose the data.  I don't necessarily agree 
but thats how the original system was written.




James Carman  
Sent by: jcar...@carmanconsulting.com
08/03/2010 02:19 PM
Please respond to
users@wicket.apache.org


To
users@wicket.apache.org
cc

Subject
Re: Encrypt Form Fields Using JS






And, you don't want to convert it before you store it in the db?  It must 
be
converted at the browser level?  Is there any more information you can 
give
us that would make this requirement not sound so crazy? :)

On Tue, Aug 3, 2010 at 2:15 PM,  wrote:

> Correct
>
>
>
>
> James Carman 
> Sent by: jcar...@carmanconsulting.com
> 08/03/2010 02:12 PM
> Please respond to
> users@wicket.apache.org
>
>
> To
> users@wicket.apache.org
> cc
>
> Subject
> Re: Encrypt Form Fields Using JS
>
>
>
>
>
>
> So, you never need to get the original values out of the database?
>
> On Tue, Aug 3, 2010 at 2:10 PM,  wrote:
>
> > An already existing system is being rewritten and the db currently
> stores
> > hashed values.  I don't disagree there are better ways to reach the 
end
> > goal, but this is the spec I am working with.
> >
> >
> >
> >
> > James Carman 
> > Sent by: jcar...@carmanconsulting.com
> > 08/03/2010 01:45 PM
> > Please respond to
> > users@wicket.apache.org
> >
> >
> > To
> > users@wicket.apache.org
> > cc
> >
> > Subject
> > Re: Encrypt Form Fields Using JS
> >
> >
> >
> >
> >
> >
> > And, what does that buy you?  Why do you want to submit one-way hashed
> > values?
> >
> > On Tue, Aug 3, 2010 at 1:37 PM,  wrote:
> >
> > > Ok, the value will be hashed, one-way...anyone have any ideas?
> > >
> > >
> > >
> > >
> > > James Carman 
> > > Sent by: jcar...@carmanconsulting.com
> > > 08/02/2010 04:42 PM
> > > Please respond to
> > > users@wicket.apache.org
> > >
> > >
> > > To
> > > users@wicket.apache.org
> > > cc
> > >
> > > Subject
> > > Re: Encrypt Form Fields Using JS
> > >
> > >
> > >
> > >
> > >
> > >
> > > Then it's not "encryption".  Encrypted data should be readable to
> those
> > > who
> > > have the "key."
> > >
> > > On Mon, Aug 2, 2010 at 3:29 PM,  wrote:
> > >
> > > > Thanks for the reply, that would work however per our business 
rules
> > the
> > > > encryption must be one-way and will not be decrypted...
> > > >
> > > >
> > > >
> > > >
> > > > Igor Vaynberg 
> > > > 08/02/2010 03:23 PM
> > > > Please respond to
> > > > users@wicket.apache.org
> > > >
> > > >
> > > > To
> > > > users@wicket.apache.org
> > > > cc
> > > >
> > > > Subject
> > > > Re: Encrypt Form Fields Using JS
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > override getinputasarray() on the field and decrypt it there, that
> way
> > > > wicket sees the decrypted value
> > > >
> > > > -igor
> > > >
> > > > On Mon, Aug 2, 2010 at 12:14 PM,   wrote:
> > > > > I totally agree, seems like double-duty that accomplishes very
> > little,
> > > > and
> > > > > actually adds overhead.  But this is another debate and the
> feature
> > > has
> > > > > been requested and must be implemented as I described...
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > "Craig McIlwee" 
> > > > > 08/02/2010 03:06 PM
> > > > > Please respond to
> > > > > users@wicket.apache.org
> > > > >
> > > > >
> > > > > To
> > > > > users@wicket.apache.org
> > > > > cc
> > > > >
> > > > > Subject
> > > > > Re: Encrypt Form Fields Using JS
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Why not use a password field to keep the valu

Re: Encrypt Form Fields Using JS

2010-08-03 Thread James Carman
And, you don't want to convert it before you store it in the db?  It must be
converted at the browser level?  Is there any more information you can give
us that would make this requirement not sound so crazy? :)

On Tue, Aug 3, 2010 at 2:15 PM,  wrote:

> Correct
>
>
>
>
> James Carman 
> Sent by: jcar...@carmanconsulting.com
> 08/03/2010 02:12 PM
> Please respond to
> users@wicket.apache.org
>
>
> To
> users@wicket.apache.org
> cc
>
> Subject
> Re: Encrypt Form Fields Using JS
>
>
>
>
>
>
> So, you never need to get the original values out of the database?
>
> On Tue, Aug 3, 2010 at 2:10 PM,  wrote:
>
> > An already existing system is being rewritten and the db currently
> stores
> > hashed values.  I don't disagree there are better ways to reach the end
> > goal, but this is the spec I am working with.
> >
> >
> >
> >
> > James Carman 
> > Sent by: jcar...@carmanconsulting.com
> > 08/03/2010 01:45 PM
> > Please respond to
> > users@wicket.apache.org
> >
> >
> > To
> > users@wicket.apache.org
> > cc
> >
> > Subject
> > Re: Encrypt Form Fields Using JS
> >
> >
> >
> >
> >
> >
> > And, what does that buy you?  Why do you want to submit one-way hashed
> > values?
> >
> > On Tue, Aug 3, 2010 at 1:37 PM,  wrote:
> >
> > > Ok, the value will be hashed, one-way...anyone have any ideas?
> > >
> > >
> > >
> > >
> > > James Carman 
> > > Sent by: jcar...@carmanconsulting.com
> > > 08/02/2010 04:42 PM
> > > Please respond to
> > > users@wicket.apache.org
> > >
> > >
> > > To
> > > users@wicket.apache.org
> > > cc
> > >
> > > Subject
> > > Re: Encrypt Form Fields Using JS
> > >
> > >
> > >
> > >
> > >
> > >
> > > Then it's not "encryption".  Encrypted data should be readable to
> those
> > > who
> > > have the "key."
> > >
> > > On Mon, Aug 2, 2010 at 3:29 PM,  wrote:
> > >
> > > > Thanks for the reply, that would work however per our business rules
> > the
> > > > encryption must be one-way and will not be decrypted...
> > > >
> > > >
> > > >
> > > >
> > > > Igor Vaynberg 
> > > > 08/02/2010 03:23 PM
> > > > Please respond to
> > > > users@wicket.apache.org
> > > >
> > > >
> > > > To
> > > > users@wicket.apache.org
> > > > cc
> > > >
> > > > Subject
> > > > Re: Encrypt Form Fields Using JS
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > override getinputasarray() on the field and decrypt it there, that
> way
> > > > wicket sees the decrypted value
> > > >
> > > > -igor
> > > >
> > > > On Mon, Aug 2, 2010 at 12:14 PM,   wrote:
> > > > > I totally agree, seems like double-duty that accomplishes very
> > little,
> > > > and
> > > > > actually adds overhead.  But this is another debate and the
> feature
> > > has
> > > > > been requested and must be implemented as I described...
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > "Craig McIlwee" 
> > > > > 08/02/2010 03:06 PM
> > > > > Please respond to
> > > > > users@wicket.apache.org
> > > > >
> > > > >
> > > > > To
> > > > > users@wicket.apache.org
> > > > > cc
> > > > >
> > > > > Subject
> > > > > Re: Encrypt Form Fields Using JS
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Why not use a password field to keep the value hidden and SSL to
> > make
> > > > sure
> > > > > there are no man in the middle attacks.  Seems like you are making
> > it
> > > > too
> > > > > hard?
> > > > >
> > > > > - Original Message -
> > > > > From: mzem...@osc.state.ny.us
> > > > > To:
> > > > > users@wicket.apache.org
> > > > > Sent: Mon,

Re: Encrypt Form Fields Using JS

2010-08-03 Thread MZemeck
Correct




James Carman  
Sent by: jcar...@carmanconsulting.com
08/03/2010 02:12 PM
Please respond to
users@wicket.apache.org


To
users@wicket.apache.org
cc

Subject
Re: Encrypt Form Fields Using JS






So, you never need to get the original values out of the database?

On Tue, Aug 3, 2010 at 2:10 PM,  wrote:

> An already existing system is being rewritten and the db currently 
stores
> hashed values.  I don't disagree there are better ways to reach the end
> goal, but this is the spec I am working with.
>
>
>
>
> James Carman 
> Sent by: jcar...@carmanconsulting.com
> 08/03/2010 01:45 PM
> Please respond to
> users@wicket.apache.org
>
>
> To
> users@wicket.apache.org
> cc
>
> Subject
> Re: Encrypt Form Fields Using JS
>
>
>
>
>
>
> And, what does that buy you?  Why do you want to submit one-way hashed
> values?
>
> On Tue, Aug 3, 2010 at 1:37 PM,  wrote:
>
> > Ok, the value will be hashed, one-way...anyone have any ideas?
> >
> >
> >
> >
> > James Carman 
> > Sent by: jcar...@carmanconsulting.com
> > 08/02/2010 04:42 PM
> > Please respond to
> > users@wicket.apache.org
> >
> >
> > To
> > users@wicket.apache.org
> > cc
> >
> > Subject
> > Re: Encrypt Form Fields Using JS
> >
> >
> >
> >
> >
> >
> > Then it's not "encryption".  Encrypted data should be readable to 
those
> > who
> > have the "key."
> >
> > On Mon, Aug 2, 2010 at 3:29 PM,  wrote:
> >
> > > Thanks for the reply, that would work however per our business rules
> the
> > > encryption must be one-way and will not be decrypted...
> > >
> > >
> > >
> > >
> > > Igor Vaynberg 
> > > 08/02/2010 03:23 PM
> > > Please respond to
> > > users@wicket.apache.org
> > >
> > >
> > > To
> > > users@wicket.apache.org
> > > cc
> > >
> > > Subject
> > > Re: Encrypt Form Fields Using JS
> > >
> > >
> > >
> > >
> > >
> > >
> > > override getinputasarray() on the field and decrypt it there, that 
way
> > > wicket sees the decrypted value
> > >
> > > -igor
> > >
> > > On Mon, Aug 2, 2010 at 12:14 PM,   wrote:
> > > > I totally agree, seems like double-duty that accomplishes very
> little,
> > > and
> > > > actually adds overhead.  But this is another debate and the 
feature
> > has
> > > > been requested and must be implemented as I described...
> > > >
> > > >
> > > >
> > > >
> > > > "Craig McIlwee" 
> > > > 08/02/2010 03:06 PM
> > > > Please respond to
> > > > users@wicket.apache.org
> > > >
> > > >
> > > > To
> > > > users@wicket.apache.org
> > > > cc
> > > >
> > > > Subject
> > > > Re: Encrypt Form Fields Using JS
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Why not use a password field to keep the value hidden and SSL to
> make
> > > sure
> > > > there are no man in the middle attacks.  Seems like you are making
> it
> > > too
> > > > hard?
> > > >
> > > > - Original Message -
> > > > From: mzem...@osc.state.ny.us
> > > > To:
> > > > users@wicket.apache.org
> > > > Sent: Mon, 02 Aug 2010 15:00:55 -0400
> > > > Subject:
> > > > Encrypt Form Fields Using JS
> > > >
> > > >
> > > >> Problem: Encrypt sensitive form fields (ie ssn) on client
> > (javascript)
> > > >>
> > > >> Solution:  Create behavior which fires javascript to hash field
> value
> > > > and
> > > >> replace original value (###-##-)
> > > >>
> > > >> This sounds simple enough, but since the length of the hashed
> string
> > > > will
> > > >> be considerably longer than the original string, validations on
> this
> > > > field
> > > >> (ssn must be nine digits) will fail.
> > > >>
> > > >> I've considered placing the hashed value into a hidden field, but
> > then
> > > > the
> > > >> unencrypted value will be posted and the hashing accomplishes
> > nothing.
> > &

Re: Encrypt Form Fields Using JS

2010-08-03 Thread James Carman
So, you never need to get the original values out of the database?

On Tue, Aug 3, 2010 at 2:10 PM,  wrote:

> An already existing system is being rewritten and the db currently stores
> hashed values.  I don't disagree there are better ways to reach the end
> goal, but this is the spec I am working with.
>
>
>
>
> James Carman 
> Sent by: jcar...@carmanconsulting.com
> 08/03/2010 01:45 PM
> Please respond to
> users@wicket.apache.org
>
>
> To
> users@wicket.apache.org
> cc
>
> Subject
> Re: Encrypt Form Fields Using JS
>
>
>
>
>
>
> And, what does that buy you?  Why do you want to submit one-way hashed
> values?
>
> On Tue, Aug 3, 2010 at 1:37 PM,  wrote:
>
> > Ok, the value will be hashed, one-way...anyone have any ideas?
> >
> >
> >
> >
> > James Carman 
> > Sent by: jcar...@carmanconsulting.com
> > 08/02/2010 04:42 PM
> > Please respond to
> > users@wicket.apache.org
> >
> >
> > To
> > users@wicket.apache.org
> > cc
> >
> > Subject
> > Re: Encrypt Form Fields Using JS
> >
> >
> >
> >
> >
> >
> > Then it's not "encryption".  Encrypted data should be readable to those
> > who
> > have the "key."
> >
> > On Mon, Aug 2, 2010 at 3:29 PM,  wrote:
> >
> > > Thanks for the reply, that would work however per our business rules
> the
> > > encryption must be one-way and will not be decrypted...
> > >
> > >
> > >
> > >
> > > Igor Vaynberg 
> > > 08/02/2010 03:23 PM
> > > Please respond to
> > > users@wicket.apache.org
> > >
> > >
> > > To
> > > users@wicket.apache.org
> > > cc
> > >
> > > Subject
> > > Re: Encrypt Form Fields Using JS
> > >
> > >
> > >
> > >
> > >
> > >
> > > override getinputasarray() on the field and decrypt it there, that way
> > > wicket sees the decrypted value
> > >
> > > -igor
> > >
> > > On Mon, Aug 2, 2010 at 12:14 PM,   wrote:
> > > > I totally agree, seems like double-duty that accomplishes very
> little,
> > > and
> > > > actually adds overhead.  But this is another debate and the feature
> > has
> > > > been requested and must be implemented as I described...
> > > >
> > > >
> > > >
> > > >
> > > > "Craig McIlwee" 
> > > > 08/02/2010 03:06 PM
> > > > Please respond to
> > > > users@wicket.apache.org
> > > >
> > > >
> > > > To
> > > > users@wicket.apache.org
> > > > cc
> > > >
> > > > Subject
> > > > Re: Encrypt Form Fields Using JS
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Why not use a password field to keep the value hidden and SSL to
> make
> > > sure
> > > > there are no man in the middle attacks.  Seems like you are making
> it
> > > too
> > > > hard?
> > > >
> > > > - Original Message -
> > > > From: mzem...@osc.state.ny.us
> > > > To:
> > > > users@wicket.apache.org
> > > > Sent: Mon, 02 Aug 2010 15:00:55 -0400
> > > > Subject:
> > > > Encrypt Form Fields Using JS
> > > >
> > > >
> > > >> Problem: Encrypt sensitive form fields (ie ssn) on client
> > (javascript)
> > > >>
> > > >> Solution:  Create behavior which fires javascript to hash field
> value
> > > > and
> > > >> replace original value (###-##-)
> > > >>
> > > >> This sounds simple enough, but since the length of the hashed
> string
> > > > will
> > > >> be considerably longer than the original string, validations on
> this
> > > > field
> > > >> (ssn must be nine digits) will fail.
> > > >>
> > > >> I've considered placing the hashed value into a hidden field, but
> > then
> > > > the
> > > >> unencrypted value will be posted and the hashing accomplishes
> > nothing.
> > > > If
> > > >> I clear out the original value I lose server-side validations.
> Anyone
> > > >> have any ideas of the best way to accomplish this?
> > > >>
>

Re: Encrypt Form Fields Using JS

2010-08-03 Thread MZemeck
An already existing system is being rewritten and the db currently stores 
hashed values.  I don't disagree there are better ways to reach the end 
goal, but this is the spec I am working with.




James Carman  
Sent by: jcar...@carmanconsulting.com
08/03/2010 01:45 PM
Please respond to
users@wicket.apache.org


To
users@wicket.apache.org
cc

Subject
Re: Encrypt Form Fields Using JS






And, what does that buy you?  Why do you want to submit one-way hashed
values?

On Tue, Aug 3, 2010 at 1:37 PM,  wrote:

> Ok, the value will be hashed, one-way...anyone have any ideas?
>
>
>
>
> James Carman 
> Sent by: jcar...@carmanconsulting.com
> 08/02/2010 04:42 PM
> Please respond to
> users@wicket.apache.org
>
>
> To
> users@wicket.apache.org
> cc
>
> Subject
> Re: Encrypt Form Fields Using JS
>
>
>
>
>
>
> Then it's not "encryption".  Encrypted data should be readable to those
> who
> have the "key."
>
> On Mon, Aug 2, 2010 at 3:29 PM,  wrote:
>
> > Thanks for the reply, that would work however per our business rules 
the
> > encryption must be one-way and will not be decrypted...
> >
> >
> >
> >
> > Igor Vaynberg 
> > 08/02/2010 03:23 PM
> > Please respond to
> > users@wicket.apache.org
> >
> >
> > To
> > users@wicket.apache.org
> > cc
> >
> > Subject
> > Re: Encrypt Form Fields Using JS
> >
> >
> >
> >
> >
> >
> > override getinputasarray() on the field and decrypt it there, that way
> > wicket sees the decrypted value
> >
> > -igor
> >
> > On Mon, Aug 2, 2010 at 12:14 PM,   wrote:
> > > I totally agree, seems like double-duty that accomplishes very 
little,
> > and
> > > actually adds overhead.  But this is another debate and the feature
> has
> > > been requested and must be implemented as I described...
> > >
> > >
> > >
> > >
> > > "Craig McIlwee" 
> > > 08/02/2010 03:06 PM
> > > Please respond to
> > > users@wicket.apache.org
> > >
> > >
> > > To
> > > users@wicket.apache.org
> > > cc
> > >
> > > Subject
> > > Re: Encrypt Form Fields Using JS
> > >
> > >
> > >
> > >
> > >
> > >
> > > Why not use a password field to keep the value hidden and SSL to 
make
> > sure
> > > there are no man in the middle attacks.  Seems like you are making 
it
> > too
> > > hard?
> > >
> > > - Original Message -
> > > From: mzem...@osc.state.ny.us
> > > To:
> > > users@wicket.apache.org
> > > Sent: Mon, 02 Aug 2010 15:00:55 -0400
> > > Subject:
> > > Encrypt Form Fields Using JS
> > >
> > >
> > >> Problem: Encrypt sensitive form fields (ie ssn) on client
> (javascript)
> > >>
> > >> Solution:  Create behavior which fires javascript to hash field 
value
> > > and
> > >> replace original value (###-##-)
> > >>
> > >> This sounds simple enough, but since the length of the hashed 
string
> > > will
> > >> be considerably longer than the original string, validations on 
this
> > > field
> > >> (ssn must be nine digits) will fail.
> > >>
> > >> I've considered placing the hashed value into a hidden field, but
> then
> > > the
> > >> unencrypted value will be posted and the hashing accomplishes
> nothing.
> > > If
> > >> I clear out the original value I lose server-side validations. 
Anyone
> > >> have any ideas of the best way to accomplish this?
> > >>
> > >>
> > >>
> > >> Notice: This communication, including any attachments, is intended
> > > solely
> > >> for the use of the individual or entity to which it is addressed.
> This
> > >> communication may contain information that is protected from
> disclosure
> > >> under State and/or Federal law. Please notify the sender 
immediately
> if
> > >> you have received this communication in error and delete this email
> > from
> > >
> > >> your system. If you are not the intended recipient, you are 
requested
> > > not
> > >> to disclose, copy, distribute or take any action in reliance on the
> > >> contents of this information.
> > >
> > > 
-

Re: Encrypt Form Fields Using JS

2010-08-03 Thread James Carman
And, what does that buy you?  Why do you want to submit one-way hashed
values?

On Tue, Aug 3, 2010 at 1:37 PM,  wrote:

> Ok, the value will be hashed, one-way...anyone have any ideas?
>
>
>
>
> James Carman 
> Sent by: jcar...@carmanconsulting.com
> 08/02/2010 04:42 PM
> Please respond to
> users@wicket.apache.org
>
>
> To
> users@wicket.apache.org
> cc
>
> Subject
> Re: Encrypt Form Fields Using JS
>
>
>
>
>
>
> Then it's not "encryption".  Encrypted data should be readable to those
> who
> have the "key."
>
> On Mon, Aug 2, 2010 at 3:29 PM,  wrote:
>
> > Thanks for the reply, that would work however per our business rules the
> > encryption must be one-way and will not be decrypted...
> >
> >
> >
> >
> > Igor Vaynberg 
> > 08/02/2010 03:23 PM
> > Please respond to
> > users@wicket.apache.org
> >
> >
> > To
> > users@wicket.apache.org
> > cc
> >
> > Subject
> > Re: Encrypt Form Fields Using JS
> >
> >
> >
> >
> >
> >
> > override getinputasarray() on the field and decrypt it there, that way
> > wicket sees the decrypted value
> >
> > -igor
> >
> > On Mon, Aug 2, 2010 at 12:14 PM,   wrote:
> > > I totally agree, seems like double-duty that accomplishes very little,
> > and
> > > actually adds overhead.  But this is another debate and the feature
> has
> > > been requested and must be implemented as I described...
> > >
> > >
> > >
> > >
> > > "Craig McIlwee" 
> > > 08/02/2010 03:06 PM
> > > Please respond to
> > > users@wicket.apache.org
> > >
> > >
> > > To
> > > users@wicket.apache.org
> > > cc
> > >
> > > Subject
> > > Re: Encrypt Form Fields Using JS
> > >
> > >
> > >
> > >
> > >
> > >
> > > Why not use a password field to keep the value hidden and SSL to make
> > sure
> > > there are no man in the middle attacks.  Seems like you are making it
> > too
> > > hard?
> > >
> > > - Original Message -
> > > From: mzem...@osc.state.ny.us
> > > To:
> > > users@wicket.apache.org
> > > Sent: Mon, 02 Aug 2010 15:00:55 -0400
> > > Subject:
> > > Encrypt Form Fields Using JS
> > >
> > >
> > >> Problem: Encrypt sensitive form fields (ie ssn) on client
> (javascript)
> > >>
> > >> Solution:  Create behavior which fires javascript to hash field value
> > > and
> > >> replace original value (###-##-)
> > >>
> > >> This sounds simple enough, but since the length of the hashed string
> > > will
> > >> be considerably longer than the original string, validations on this
> > > field
> > >> (ssn must be nine digits) will fail.
> > >>
> > >> I've considered placing the hashed value into a hidden field, but
> then
> > > the
> > >> unencrypted value will be posted and the hashing accomplishes
> nothing.
> > > If
> > >> I clear out the original value I lose server-side validations. Anyone
> > >> have any ideas of the best way to accomplish this?
> > >>
> > >>
> > >>
> > >> Notice: This communication, including any attachments, is intended
> > > solely
> > >> for the use of the individual or entity to which it is addressed.
> This
> > >> communication may contain information that is protected from
> disclosure
> > >> under State and/or Federal law. Please notify the sender immediately
> if
> > >> you have received this communication in error and delete this email
> > from
> > >
> > >> your system. If you are not the intended recipient, you are requested
> > > not
> > >> to disclose, copy, distribute or take any action in reliance on the
> > >> contents of this information.
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > > For additional commands, e-mail: users-h...@wicket.apache.org
> > >
> > >
> > >
> > >
> > >
> > >
> > > Notice: This communication, including any attachments, is intended
> > solely
> > > for the use of the individual or entity to which it 

Re: Encrypt Form Fields Using JS

2010-08-03 Thread MZemeck
Ok, the value will be hashed, one-way...anyone have any ideas?




James Carman  
Sent by: jcar...@carmanconsulting.com
08/02/2010 04:42 PM
Please respond to
users@wicket.apache.org


To
users@wicket.apache.org
cc

Subject
Re: Encrypt Form Fields Using JS






Then it's not "encryption".  Encrypted data should be readable to those 
who
have the "key."

On Mon, Aug 2, 2010 at 3:29 PM,  wrote:

> Thanks for the reply, that would work however per our business rules the
> encryption must be one-way and will not be decrypted...
>
>
>
>
> Igor Vaynberg 
> 08/02/2010 03:23 PM
> Please respond to
> users@wicket.apache.org
>
>
> To
> users@wicket.apache.org
> cc
>
> Subject
> Re: Encrypt Form Fields Using JS
>
>
>
>
>
>
> override getinputasarray() on the field and decrypt it there, that way
> wicket sees the decrypted value
>
> -igor
>
> On Mon, Aug 2, 2010 at 12:14 PM,   wrote:
> > I totally agree, seems like double-duty that accomplishes very little,
> and
> > actually adds overhead.  But this is another debate and the feature 
has
> > been requested and must be implemented as I described...
> >
> >
> >
> >
> > "Craig McIlwee" 
> > 08/02/2010 03:06 PM
> > Please respond to
> > users@wicket.apache.org
> >
> >
> > To
> > users@wicket.apache.org
> > cc
> >
> > Subject
> > Re: Encrypt Form Fields Using JS
> >
> >
> >
> >
> >
> >
> > Why not use a password field to keep the value hidden and SSL to make
> sure
> > there are no man in the middle attacks.  Seems like you are making it
> too
> > hard?
> >
> > - Original Message -
> > From: mzem...@osc.state.ny.us
> > To:
> > users@wicket.apache.org
> > Sent: Mon, 02 Aug 2010 15:00:55 -0400
> > Subject:
> > Encrypt Form Fields Using JS
> >
> >
> >> Problem: Encrypt sensitive form fields (ie ssn) on client 
(javascript)
> >>
> >> Solution:  Create behavior which fires javascript to hash field value
> > and
> >> replace original value (###-##-)
> >>
> >> This sounds simple enough, but since the length of the hashed string
> > will
> >> be considerably longer than the original string, validations on this
> > field
> >> (ssn must be nine digits) will fail.
> >>
> >> I've considered placing the hashed value into a hidden field, but 
then
> > the
> >> unencrypted value will be posted and the hashing accomplishes 
nothing.
> > If
> >> I clear out the original value I lose server-side validations. Anyone
> >> have any ideas of the best way to accomplish this?
> >>
> >>
> >>
> >> Notice: This communication, including any attachments, is intended
> > solely
> >> for the use of the individual or entity to which it is addressed. 
This
> >> communication may contain information that is protected from 
disclosure
> >> under State and/or Federal law. Please notify the sender immediately 
if
> >> you have received this communication in error and delete this email
> from
> >
> >> your system. If you are not the intended recipient, you are requested
> > not
> >> to disclose, copy, distribute or take any action in reliance on the
> >> contents of this information.
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
> >
> >
> >
> >
> >
> > Notice: This communication, including any attachments, is intended
> solely
> > for the use of the individual or entity to which it is addressed. This
> > communication may contain information that is protected from 
disclosure
> > under State and/or Federal law. Please notify the sender immediately 
if
> > you have received this communication in error and delete this email 
from
> > your system. If you are not the intended recipient, you are requested
> not
> > to disclose, copy, distribute or take any action in reliance on the
> > contents of this information.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
>
>
>
>
> Notice: This communication, including any attachments, is intended 
solely
> for the use of the individual or entity to which it is addressed. T

Re: Encrypt Form Fields Using JS

2010-08-02 Thread James Carman
Then it's not "encryption".  Encrypted data should be readable to those who
have the "key."

On Mon, Aug 2, 2010 at 3:29 PM,  wrote:

> Thanks for the reply, that would work however per our business rules the
> encryption must be one-way and will not be decrypted...
>
>
>
>
> Igor Vaynberg 
> 08/02/2010 03:23 PM
> Please respond to
> users@wicket.apache.org
>
>
> To
> users@wicket.apache.org
> cc
>
> Subject
> Re: Encrypt Form Fields Using JS
>
>
>
>
>
>
> override getinputasarray() on the field and decrypt it there, that way
> wicket sees the decrypted value
>
> -igor
>
> On Mon, Aug 2, 2010 at 12:14 PM,   wrote:
> > I totally agree, seems like double-duty that accomplishes very little,
> and
> > actually adds overhead.  But this is another debate and the feature has
> > been requested and must be implemented as I described...
> >
> >
> >
> >
> > "Craig McIlwee" 
> > 08/02/2010 03:06 PM
> > Please respond to
> > users@wicket.apache.org
> >
> >
> > To
> > users@wicket.apache.org
> > cc
> >
> > Subject
> > Re: Encrypt Form Fields Using JS
> >
> >
> >
> >
> >
> >
> > Why not use a password field to keep the value hidden and SSL to make
> sure
> > there are no man in the middle attacks.  Seems like you are making it
> too
> > hard?
> >
> > - Original Message -
> > From: mzem...@osc.state.ny.us
> > To:
> > users@wicket.apache.org
> > Sent: Mon, 02 Aug 2010 15:00:55 -0400
> > Subject:
> > Encrypt Form Fields Using JS
> >
> >
> >> Problem: Encrypt sensitive form fields (ie ssn) on client (javascript)
> >>
> >> Solution:  Create behavior which fires javascript to hash field value
> > and
> >> replace original value (###-##-)
> >>
> >> This sounds simple enough, but since the length of the hashed string
> > will
> >> be considerably longer than the original string, validations on this
> > field
> >> (ssn must be nine digits) will fail.
> >>
> >> I've considered placing the hashed value into a hidden field, but then
> > the
> >> unencrypted value will be posted and the hashing accomplishes nothing.
> > If
> >> I clear out the original value I lose server-side validations.  Anyone
> >> have any ideas of the best way to accomplish this?
> >>
> >>
> >>
> >> Notice: This communication, including any attachments, is intended
> > solely
> >> for the use of the individual or entity to which it is addressed. This
> >> communication may contain information that is protected from disclosure
> >> under State and/or Federal law. Please notify the sender immediately if
> >> you have received this communication in error and delete this email
> from
> >
> >> your system. If you are not the intended recipient, you are requested
> > not
> >> to disclose, copy, distribute or take any action in reliance on the
> >> contents of this information.
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
> >
> >
> >
> >
> >
> > Notice: This communication, including any attachments, is intended
> solely
> > for the use of the individual or entity to which it is addressed. This
> > communication may contain information that is protected from disclosure
> > under State and/or Federal law. Please notify the sender immediately if
> > you have received this communication in error and delete this email from
> > your system. If you are not the intended recipient, you are requested
> not
> > to disclose, copy, distribute or take any action in reliance on the
> > contents of this information.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
>
>
>
>
> Notice: This communication, including any attachments, is intended solely
> for the use of the individual or entity to which it is addressed. This
> communication may contain information that is protected from disclosure
> under State and/or Federal law. Please notify the sender immediately if
> you have received this communication in error and delete this email from
> your system. If you are not the intended recipient, you are requested not
> to disclose, copy, distribute or take any action in reliance on the
> contents of this information.
>


Re: Encrypt Form Fields Using JS

2010-08-02 Thread MZemeck
The only thing I've come up with to meet all the requirements is to set 
the hashed value to a hidden field, and replace the original value 
(123-45-6789) with all nines (999-99-).  This would allow the 
validator to pass but puts a requirement on the js to validate the 
original value, ie it should not replace a 'Q' with a '9'




Igor Vaynberg  
08/02/2010 03:46 PM
Please respond to
users@wicket.apache.org


To
users@wicket.apache.org
cc

Subject
Re: Encrypt Form Fields Using JS






so how do you expect to validate on server side???

-igor

On Mon, Aug 2, 2010 at 12:29 PM,   wrote:
> Thanks for the reply, that would work however per our business rules the
> encryption must be one-way and will not be decrypted...
>
>
>
>
> Igor Vaynberg 
> 08/02/2010 03:23 PM
> Please respond to
> users@wicket.apache.org
>
>
> To
> users@wicket.apache.org
> cc
>
> Subject
> Re: Encrypt Form Fields Using JS
>
>
>
>
>
>
> override getinputasarray() on the field and decrypt it there, that way
> wicket sees the decrypted value
>
> -igor
>
> On Mon, Aug 2, 2010 at 12:14 PM,   wrote:
>> I totally agree, seems like double-duty that accomplishes very little,
> and
>> actually adds overhead.  But this is another debate and the feature has
>> been requested and must be implemented as I described...
>>
>>
>>
>>
>> "Craig McIlwee" 
>> 08/02/2010 03:06 PM
>> Please respond to
>> users@wicket.apache.org
>>
>>
>> To
>> users@wicket.apache.org
>> cc
>>
>> Subject
>> Re: Encrypt Form Fields Using JS
>>
>>
>>
>>
>>
>>
>> Why not use a password field to keep the value hidden and SSL to make
> sure
>> there are no man in the middle attacks.  Seems like you are making it
> too
>> hard?
>>
>> - Original Message -
>> From: mzem...@osc.state.ny.us
>> To:
>> users@wicket.apache.org
>> Sent: Mon, 02 Aug 2010 15:00:55 -0400
>> Subject:
>> Encrypt Form Fields Using JS
>>
>>
>>> Problem: Encrypt sensitive form fields (ie ssn) on client (javascript)
>>>
>>> Solution:  Create behavior which fires javascript to hash field value
>> and
>>> replace original value (###-##-)
>>>
>>> This sounds simple enough, but since the length of the hashed string
>> will
>>> be considerably longer than the original string, validations on this
>> field
>>> (ssn must be nine digits) will fail.
>>>
>>> I've considered placing the hashed value into a hidden field, but then
>> the
>>> unencrypted value will be posted and the hashing accomplishes nothing.
>> If
>>> I clear out the original value I lose server-side validations.  Anyone
>>> have any ideas of the best way to accomplish this?
>>>
>>>
>>>
>>> Notice: This communication, including any attachments, is intended
>> solely
>>> for the use of the individual or entity to which it is addressed. This
>>> communication may contain information that is protected from 
disclosure
>>> under State and/or Federal law. Please notify the sender immediately 
if
>>> you have received this communication in error and delete this email
> from
>>
>>> your system. If you are not the intended recipient, you are requested
>> not
>>> to disclose, copy, distribute or take any action in reliance on the
>>> contents of this information.
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>>
>>
>>
>>
>> Notice: This communication, including any attachments, is intended
> solely
>> for the use of the individual or entity to which it is addressed. This
>> communication may contain information that is protected from disclosure
>> under State and/or Federal law. Please notify the sender immediately if
>> you have received this communication in error and delete this email 
from
>> your system. If you are not the intended recipient, you are requested
> not
>> to disclose, copy, distribute or take any action in reliance on the
>> contents of this information.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
>
>
>
>
> Notice: This communication, including any

Re: Encrypt Form Fields Using JS

2010-08-02 Thread Igor Vaynberg
so how do you expect to validate on server side???

-igor

On Mon, Aug 2, 2010 at 12:29 PM,   wrote:
> Thanks for the reply, that would work however per our business rules the
> encryption must be one-way and will not be decrypted...
>
>
>
>
> Igor Vaynberg 
> 08/02/2010 03:23 PM
> Please respond to
> users@wicket.apache.org
>
>
> To
> users@wicket.apache.org
> cc
>
> Subject
> Re: Encrypt Form Fields Using JS
>
>
>
>
>
>
> override getinputasarray() on the field and decrypt it there, that way
> wicket sees the decrypted value
>
> -igor
>
> On Mon, Aug 2, 2010 at 12:14 PM,   wrote:
>> I totally agree, seems like double-duty that accomplishes very little,
> and
>> actually adds overhead.  But this is another debate and the feature has
>> been requested and must be implemented as I described...
>>
>>
>>
>>
>> "Craig McIlwee" 
>> 08/02/2010 03:06 PM
>> Please respond to
>> users@wicket.apache.org
>>
>>
>> To
>> users@wicket.apache.org
>> cc
>>
>> Subject
>> Re: Encrypt Form Fields Using JS
>>
>>
>>
>>
>>
>>
>> Why not use a password field to keep the value hidden and SSL to make
> sure
>> there are no man in the middle attacks.  Seems like you are making it
> too
>> hard?
>>
>> - Original Message -
>> From: mzem...@osc.state.ny.us
>> To:
>> users@wicket.apache.org
>> Sent: Mon, 02 Aug 2010 15:00:55 -0400
>> Subject:
>> Encrypt Form Fields Using JS
>>
>>
>>> Problem: Encrypt sensitive form fields (ie ssn) on client (javascript)
>>>
>>> Solution:  Create behavior which fires javascript to hash field value
>> and
>>> replace original value (###-##-)
>>>
>>> This sounds simple enough, but since the length of the hashed string
>> will
>>> be considerably longer than the original string, validations on this
>> field
>>> (ssn must be nine digits) will fail.
>>>
>>> I've considered placing the hashed value into a hidden field, but then
>> the
>>> unencrypted value will be posted and the hashing accomplishes nothing.
>> If
>>> I clear out the original value I lose server-side validations.  Anyone
>>> have any ideas of the best way to accomplish this?
>>>
>>>
>>>
>>> Notice: This communication, including any attachments, is intended
>> solely
>>> for the use of the individual or entity to which it is addressed. This
>>> communication may contain information that is protected from disclosure
>>> under State and/or Federal law. Please notify the sender immediately if
>>> you have received this communication in error and delete this email
> from
>>
>>> your system. If you are not the intended recipient, you are requested
>> not
>>> to disclose, copy, distribute or take any action in reliance on the
>>> contents of this information.
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>>
>>
>>
>>
>> Notice: This communication, including any attachments, is intended
> solely
>> for the use of the individual or entity to which it is addressed. This
>> communication may contain information that is protected from disclosure
>> under State and/or Federal law. Please notify the sender immediately if
>> you have received this communication in error and delete this email from
>> your system. If you are not the intended recipient, you are requested
> not
>> to disclose, copy, distribute or take any action in reliance on the
>> contents of this information.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
>
>
>
>
> Notice: This communication, including any attachments, is intended solely
> for the use of the individual or entity to which it is addressed. This
> communication may contain information that is protected from disclosure
> under State and/or Federal law. Please notify the sender immediately if
> you have received this communication in error and delete this email from
> your system. If you are not the intended recipient, you are requested not
> to disclose, copy, distribute or take any action in reliance on the
> contents of this information.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Encrypt Form Fields Using JS

2010-08-02 Thread MZemeck
Thanks for the reply, that would work however per our business rules the 
encryption must be one-way and will not be decrypted...




Igor Vaynberg  
08/02/2010 03:23 PM
Please respond to
users@wicket.apache.org


To
users@wicket.apache.org
cc

Subject
Re: Encrypt Form Fields Using JS






override getinputasarray() on the field and decrypt it there, that way
wicket sees the decrypted value

-igor

On Mon, Aug 2, 2010 at 12:14 PM,   wrote:
> I totally agree, seems like double-duty that accomplishes very little, 
and
> actually adds overhead.  But this is another debate and the feature has
> been requested and must be implemented as I described...
>
>
>
>
> "Craig McIlwee" 
> 08/02/2010 03:06 PM
> Please respond to
> users@wicket.apache.org
>
>
> To
> users@wicket.apache.org
> cc
>
> Subject
> Re: Encrypt Form Fields Using JS
>
>
>
>
>
>
> Why not use a password field to keep the value hidden and SSL to make 
sure
> there are no man in the middle attacks.  Seems like you are making it 
too
> hard?
>
> - Original Message -
> From: mzem...@osc.state.ny.us
> To:
> users@wicket.apache.org
> Sent: Mon, 02 Aug 2010 15:00:55 -0400
> Subject:
> Encrypt Form Fields Using JS
>
>
>> Problem: Encrypt sensitive form fields (ie ssn) on client (javascript)
>>
>> Solution:  Create behavior which fires javascript to hash field value
> and
>> replace original value (###-##-)
>>
>> This sounds simple enough, but since the length of the hashed string
> will
>> be considerably longer than the original string, validations on this
> field
>> (ssn must be nine digits) will fail.
>>
>> I've considered placing the hashed value into a hidden field, but then
> the
>> unencrypted value will be posted and the hashing accomplishes nothing.
> If
>> I clear out the original value I lose server-side validations.  Anyone
>> have any ideas of the best way to accomplish this?
>>
>>
>>
>> Notice: This communication, including any attachments, is intended
> solely
>> for the use of the individual or entity to which it is addressed. This
>> communication may contain information that is protected from disclosure
>> under State and/or Federal law. Please notify the sender immediately if
>> you have received this communication in error and delete this email 
from
>
>> your system. If you are not the intended recipient, you are requested
> not
>> to disclose, copy, distribute or take any action in reliance on the
>> contents of this information.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
>
>
>
>
> Notice: This communication, including any attachments, is intended 
solely
> for the use of the individual or entity to which it is addressed. This
> communication may contain information that is protected from disclosure
> under State and/or Federal law. Please notify the sender immediately if
> you have received this communication in error and delete this email from
> your system. If you are not the intended recipient, you are requested 
not
> to disclose, copy, distribute or take any action in reliance on the
> contents of this information.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org






Notice: This communication, including any attachments, is intended solely 
for the use of the individual or entity to which it is addressed. This 
communication may contain information that is protected from disclosure 
under State and/or Federal law. Please notify the sender immediately if 
you have received this communication in error and delete this email from 
your system. If you are not the intended recipient, you are requested not 
to disclose, copy, distribute or take any action in reliance on the 
contents of this information.

Re: Encrypt Form Fields Using JS

2010-08-02 Thread Igor Vaynberg
override getinputasarray() on the field and decrypt it there, that way
wicket sees the decrypted value

-igor

On Mon, Aug 2, 2010 at 12:14 PM,   wrote:
> I totally agree, seems like double-duty that accomplishes very little, and
> actually adds overhead.  But this is another debate and the feature has
> been requested and must be implemented as I described...
>
>
>
>
> "Craig McIlwee" 
> 08/02/2010 03:06 PM
> Please respond to
> users@wicket.apache.org
>
>
> To
> users@wicket.apache.org
> cc
>
> Subject
> Re: Encrypt Form Fields Using JS
>
>
>
>
>
>
> Why not use a password field to keep the value hidden and SSL to make sure
> there are no man in the middle attacks.  Seems like you are making it too
> hard?
>
> - Original Message -
> From: mzem...@osc.state.ny.us
> To:
> users@wicket.apache.org
> Sent: Mon, 02 Aug 2010 15:00:55 -0400
> Subject:
> Encrypt Form Fields Using JS
>
>
>> Problem: Encrypt sensitive form fields (ie ssn) on client (javascript)
>>
>> Solution:  Create behavior which fires javascript to hash field value
> and
>> replace original value (###-##-)
>>
>> This sounds simple enough, but since the length of the hashed string
> will
>> be considerably longer than the original string, validations on this
> field
>> (ssn must be nine digits) will fail.
>>
>> I've considered placing the hashed value into a hidden field, but then
> the
>> unencrypted value will be posted and the hashing accomplishes nothing.
> If
>> I clear out the original value I lose server-side validations.  Anyone
>> have any ideas of the best way to accomplish this?
>>
>>
>>
>> Notice: This communication, including any attachments, is intended
> solely
>> for the use of the individual or entity to which it is addressed. This
>> communication may contain information that is protected from disclosure
>> under State and/or Federal law. Please notify the sender immediately if
>> you have received this communication in error and delete this email from
>
>> your system. If you are not the intended recipient, you are requested
> not
>> to disclose, copy, distribute or take any action in reliance on the
>> contents of this information.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
>
>
>
>
> Notice: This communication, including any attachments, is intended solely
> for the use of the individual or entity to which it is addressed. This
> communication may contain information that is protected from disclosure
> under State and/or Federal law. Please notify the sender immediately if
> you have received this communication in error and delete this email from
> your system. If you are not the intended recipient, you are requested not
> to disclose, copy, distribute or take any action in reliance on the
> contents of this information.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Encrypt Form Fields Using JS

2010-08-02 Thread MZemeck
I totally agree, seems like double-duty that accomplishes very little, and 
actually adds overhead.  But this is another debate and the feature has 
been requested and must be implemented as I described...




"Craig McIlwee"  
08/02/2010 03:06 PM
Please respond to
users@wicket.apache.org


To
users@wicket.apache.org
cc

Subject
Re: Encrypt Form Fields Using JS






Why not use a password field to keep the value hidden and SSL to make sure 
there are no man in the middle attacks.  Seems like you are making it too 
hard?

- Original Message -
From: mzem...@osc.state.ny.us
To:
users@wicket.apache.org
Sent: Mon, 02 Aug 2010 15:00:55 -0400
Subject:
Encrypt Form Fields Using JS


> Problem: Encrypt sensitive form fields (ie ssn) on client (javascript)
> 
> Solution:  Create behavior which fires javascript to hash field value 
and 
> replace original value (###-##-)
> 
> This sounds simple enough, but since the length of the hashed string 
will 
> be considerably longer than the original string, validations on this 
field 
> (ssn must be nine digits) will fail.
> 
> I've considered placing the hashed value into a hidden field, but then 
the 
> unencrypted value will be posted and the hashing accomplishes nothing. 
If 
> I clear out the original value I lose server-side validations.  Anyone 
> have any ideas of the best way to accomplish this?
> 
> 
> 
> Notice: This communication, including any attachments, is intended 
solely 
> for the use of the individual or entity to which it is addressed. This 
> communication may contain information that is protected from disclosure 
> under State and/or Federal law. Please notify the sender immediately if 
> you have received this communication in error and delete this email from 

> your system. If you are not the intended recipient, you are requested 
not 
> to disclose, copy, distribute or take any action in reliance on the 
> contents of this information.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org






Notice: This communication, including any attachments, is intended solely 
for the use of the individual or entity to which it is addressed. This 
communication may contain information that is protected from disclosure 
under State and/or Federal law. Please notify the sender immediately if 
you have received this communication in error and delete this email from 
your system. If you are not the intended recipient, you are requested not 
to disclose, copy, distribute or take any action in reliance on the 
contents of this information.

Re: Encrypt Form Fields Using JS

2010-08-02 Thread Craig McIlwee
Why not use a password field to keep the value hidden and SSL to make sure 
there are no man in the middle attacks.  Seems like you are making it too hard?

- Original Message -
From: mzem...@osc.state.ny.us
To:
users@wicket.apache.org
Sent: Mon, 02 Aug 2010 15:00:55 -0400
Subject:
Encrypt Form Fields Using JS


> Problem: Encrypt sensitive form fields (ie ssn) on client (javascript)
> 
> Solution:  Create behavior which fires javascript to hash field value and 
> replace original value (###-##-)
> 
> This sounds simple enough, but since the length of the hashed string will 
> be considerably longer than the original string, validations on this field 
> (ssn must be nine digits) will fail.
> 
> I've considered placing the hashed value into a hidden field, but then the 
> unencrypted value will be posted and the hashing accomplishes nothing.  If 
> I clear out the original value I lose server-side validations.  Anyone 
> have any ideas of the best way to accomplish this?
> 
> 
> 
> Notice: This communication, including any attachments, is intended solely 
> for the use of the individual or entity to which it is addressed. This 
> communication may contain information that is protected from disclosure 
> under State and/or Federal law. Please notify the sender immediately if 
> you have received this communication in error and delete this email from 
> your system. If you are not the intended recipient, you are requested not 
> to disclose, copy, distribute or take any action in reliance on the 
> contents of this information.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org