You could write a custom applet, which could use any encryption algorithm
you prefer.
-Original Message-
From: Sam Newman [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 12, 2001 2:35 PM
To: [EMAIL PROTECTED]
Subject: Encrypting password
Am I right in saying the only method for encryptin
[EMAIL PROTECTED]]
>Sent: Monday, March 12, 2001 3:44 PM
>To: '[EMAIL PROTECTED]'
>Subject: RE: Encrypting password
>
>
>You could write a custom applet, which could use any
>encryption algorithm
>you prefer.
>
>-Original Message-
>From: Sam Newma
ify in servlet the
password for this user via md5 is equal to the
password string you received :
ie: http://pajhome.org.uk/crypt/md5/index.html
>-Original Message-
>From: Samson, Lyndon [IT] [mailto:[EMAIL PROTECTED]]
>Sent: Monday, March 12, 2001 3:44 PM
>To: '[EMAIL PR
On Mon, 12 Mar 2001, Samson, Lyndon [IT] wrote:
> You could write a custom applet, which could use any encryption algorithm
> you prefer.
>
> -Original Message-
> From: Sam Newman [mailto:[EMAIL PROTECTED]]
> Sent: Monday, March 12, 2001 2:35 PM
> To: [EMAIL PROTECTED]
> Subject: Encry
: Monday, March 12, 2001 3:05 PM
To: [EMAIL PROTECTED]
Subject: RE: Encrypting password
You could also use a little javascript to send
password coded with md5 and verify in servlet the
password for this user via md5 is equal to the
password string you received :
ie: http://pajhome.org.uk/crypt/md5
gt;>From: Samson, Lyndon [IT] [mailto:[EMAIL PROTECTED]]
>>Sent: Monday, March 12, 2001 3:44 PM
>>To: '[EMAIL PROTECTED]'
>>Subject: RE: Encrypting password
>>
>>
>>You could write a custom applet, which could use any
>>encryption algorithm
>
Courier a disk :-)
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 12, 2001 3:09 PM
To: '[EMAIL PROTECTED]'
Subject: RE: Encrypting password
On Mon, 12 Mar 2001, Samson, Lyndon [IT] wrote:
> You could write a custom applet, wh
2001 10:18 AM
> To: [EMAIL PROTECTED]
> Subject: RE: Encrypting password
>
>
> >The problem with this approach is that, without a
> >challenge-response, having the MD5 digest of the password is
> >as good as having the password.
>
> What is the challenge-respo
rom: GOMEZ Henri <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, March 12, 2001 3:18 PM
Subject: RE: Encrypting password
> >The problem with this approach is that, without a
> >challenge-response, having the MD5 digest of the password is
> >as good as having
md5 digest
in the clear where it can be sniffed.
Jin
> -Original Message-
> From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
> Sent: Monday, March 12, 2001 10:18 AM
> To: [EMAIL PROTECTED]
> Subject: RE: Encrypting password
>
>
> >The problem with this approach is
On Mon, 12 Mar 2001, DONNIE HALE wrote:
> The problem with this approach is that, without a challenge-response, having the MD5
>digest of the password is as good as having the password.
>
> Donnie
>
> >>> [EMAIL PROTECTED] 03/12/01 10:05AM >>>
> You could also use a little javascript to send
> p
On Mon, 12 Mar 2001, GOMEZ Henri wrote:
> >The problem with this approach is that, without a
> >challenge-response, having the MD5 digest of the password is
> >as good as having the password.
>
> What is the challenge-response ?
>
> The MD5/SHA1 digest is good over secure line.
>
> 1) Store in DB
bject: Re: Encrypting password
Currently the login is handled by a servlet (actually an RMI client) which
cimmunicates with a remote database to get the info. I just don't want to
send the users password unencrypted over the web. I'm really looking to
avoid using SSL if possible. We want
On Mon, 12 Mar 2001, Byung Jin Chun wrote:
> JMHO,
> but I think the point is if you have ssl available, why send
> a digest, and if you don't, then you are sending the md5 digest
> in the clear where it can be sniffed.
This is why you use the challenge-reposne. The server gives a challenge
(l
> If you are using SSL then why even bother hashing the password?
The one reason I can think of hashing a password even if you have SSL is
because then the password stored on the server must also be hashed to be
useful. It is better to *not* store passwrods on the server in plain
text, since if
little javascript to send
>> password coded with md5 and verify in servlet the
>> password for this user via md5 is equal to the
>> password string you received :
>>
>> ie: http://pajhome.org.uk/crypt/md5/index.html
>>
>>
>>
>>> -Original Me
Joe Wrote:
> If you are using SSL then why even bother hashing the password? I think
> the original poster said he/she could not use SSL (but I may be mistaken).
Well, we want to avoid SSL if possible. Certificates for the servers aren't
that cheap, and we could potentially have quite a few serve
> if the app is accessed through a single URL and loadbalanced / proxied,
you
> still only need the one SSL cert: it's the URL, not the IP address, that
> counts.
The situation we are in is where users connect to a server, which is our
customers servers. Each customer server would still have t
On Tuesday 13 March 2001 09:59, Sam Newman wrote:
> Joe Wrote:
> > If you are using SSL then why even bother hashing the password? I think
> > the original poster said he/she could not use SSL (but I may be
> > mistaken).
>
> Well, we want to avoid SSL if possible. Certificates for the servers are
> As far as whether to do MD5 or SHA, it really depends on the ease of
> computing those hashes at the browser. There are javascript MD5
> algorithms available on the web, but I'm not aware of any SHA (you can
> always write you're own). You could also do it inside an applet, but
> if you're no
guess from what you're saying that these different do _not_ have
the same URL name. Am I right?
-Original Message-
From: Sam Newman [mailto:[EMAIL PROTECTED]]
Sent: 13. mars 2001 09:01
To: [EMAIL PROTECTED]
Subject: Re: Encrypting password
> if the app is accessed throug
- Original Message -
From: Stefán F. Stefánsson <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, March 13, 2001 9:53 AM
Subject: RE: Encrypting password
> sorry for butting in but...
>
> if your customer server has the same URL name (ie.
> support
browser compatible to
security/crypto api;
listen();//my socket is open to listen your reply
shailendra
- Original Message -
From: Sam Newman <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, March 13, 2001 2:37 PM
Subject: Re: Encrypting password
>
> > As
t;[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, March 12, 2001 11:26 PM
Subject: Re: Encrypting password
> hi
> to all of you
>
> i am trying to write an applet that usaes java security api/java
> cryptography api so to run that applet in borwser(ie/netscape)
>
On Tue, 13 Mar 2001, Sam Newman wrote:
> do you mean that its the wrong version of java? Without the plugin the
> browsers should support 1.1.6 java, which I understoof was enough for the
> java crypto stuff. Is it simply that the relevent jars aren't being
> downloaded by the applet?
>
> sam
: <[EMAIL PROTECTED]>
Sent: Tuesday, March 13, 2001 6:35 PM
Subject: Re: Encrypting password
>
>
> On Tue, 13 Mar 2001, Sam Newman wrote:
>
> > do you mean that its the wrong version of java? Without the plugin the
> > browsers should support 1.1.6 java, which I unders
On Tue, 13 Mar 2001, Shailendra wrote:
> hi
>
> can u please put some more light on your line
> > you could however use aba.* or the baltimore packages.
> and one more thing is it we dont have any plug in type of thing for this
> kind of job(security api support)
>
some companies copied the
On Tue, 13 Mar 2001, Francisco M. Marzoa Alonso wrote:
> >
> > Well, we want to avoid SSL if possible. Certificates for the servers aren't
> > that cheap, and we could potentially have quite a few servers. As we're a
> > startup company, I don't really want to commit ourselves to get SSL, seeing
>
> yep - our customers may actually me isp's, and the end users isp's
> customers. I think long term we will go the SSL route, but for beta use an
> applet. That said, i feel better about using our 1024 bit encryption for the
> passwords than 128 bit encryption SSL uses - i don't see 128bit as bein
Tim Wrote:
> If you are using passwords as the key, then it is unlikely that using
> 1024 vs. 128 bit means a bit of difference. Unless you are requiring
> that users use a 250 character password. The entropy of 6-10 digit
> passwords is such that they are the weak point no matter how many bits
>
If you just need a test certificate for experimentation, check with Thawte:
theirs are free for application testing, and they don't trigger the
client-side 'Add a Certificate' dialog. Once you work out the bugs, try
Verisign or RSA for a production certificate.
- Roby
Sam Newman wrote:
> Tim Wr
--On Tuesday, March 13, 2001 10:04:14 AM +0100 "Francisco M. Marzoa
Alonso" <[EMAIL PROTECTED]> wrote:
> On Tuesday 13 March 2001 09:59, Sam Newman wrote:
>> Joe Wrote:
>> > If you are using SSL then why even bother hashing the password? I
>> > think the original poster said he/she could not us
32 matches
Mail list logo
