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
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 to
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 aren't
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 not
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 through a single URL
- Original Message -
From: Stefn F. Stefnsson [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.btinternet.com) then it doesn't matter
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 far as whether to do MD5
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)
they should also assist these api
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
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 understoof was enough for
the
java crypto stuff
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
as
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 being
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
you
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
--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 use SSL (but
Am I right in saying the only method for encrypting user entered data (e.g
from client desktopn browser to web server) is SSL?
sam
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
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
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 Newman [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 12, 2001 2:35
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 PROTECTED]'
Subject: RE: Encrypting password
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: Encrypting
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 Newman [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 12, 2001 2:35 PM
To: [EMAIL PROTECTED]
Subject: Encrypting password
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, which could use
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-response ?
The MD5/SHA1 digest is good over secure line.
1) Store
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 the password.
What is the challenge-response
ffed.
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 that, without a
challenge-response, having the MD5 digest of the password is
as good
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
password coded
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 or LDAP
: 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 to avoid having
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
(like
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
/index.html
-Original Message-
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
you prefer.
-Original
32 matches
Mail list logo
