Twylite wrote:
The only way to solve this problem - securing both the wire and the
server storage - is to move to a more advanced cryptographic protocol
(preferably asymmetric crypto). That is not workable however, as it
would leave no way to log on through the web interface (which is
Hi,
CHAP: (originally from PPP)
send a challenge string from server to client. The client sends back
H(challenge || password). Someone now has to brute-force the password
if the communication is intercepted. The downside is that the password
is stored in plaintext on the server.
Another
Hi,
Do the same thing as at present, in that the client sends the password hashed
and not in cleartext.
The server takes that hashed value and the user name, hashes again (perhaps
with a different algorithm) and compares to what it has stored. Neither the
original password (stored in the
On Jan 9, 2010, at 5:24 PM, D. Richard Hipp wrote:
OK. Beginning with http://www.fossil-scm.org/fossil/ci/cfe33dcf92
Fossil will store passwords on servers as either cleartext or as a
SHA1 hash of the password. ...
I have tagged this change experimental for now. I'm planning to
make
I agree with your conclusions. for my part I'm just glad that my
password is not stored in plain text in the fossil database -
especially when I don't control the repository. I know that the
transmissions are no more secure than before.
many people, for better or worse, reuse usernames and
The most common approaches I know of:
Unix-style password file: store salt || H(salt || password)
The 'salt' value is a random string used to make attacks that precompute
the hash values of common passwords harder. The downside is that the
client has to send the password in plaintext.
I didn't see an option, perhaps it's not even on the list of requests... but
when I look at the 'user' table, the user's password is stored in cleartext.
Having my fossil file on a shared server, this makes me a bit nervous. Anyone
who has access to that file can read all the user passwords.
I noticed this the other day. I am not on a shared server and it makes me a bit
nervous. Also, it's not really fair to people working on your project as many
people have a common password (good or bad).
Jeremy
Ron Aaron r...@ronware.org wrote:
I didn't see an option, perhaps it's not even on
On Saturday 09 January 2010 18:21:00 D. Richard Hipp wrote:
There is a trade-off.
You can store an cryptographic checksum of the password in the user
table. ...
Or you can store the cleartext password in the user
table and send a cryptographic checksum of the password...
There is another
On Jan 9, 2010, at 11:29 AM, Ron Aaron wrote:
On Saturday 09 January 2010 18:21:00 D. Richard Hipp wrote:
There is a trade-off.
You can store an cryptographic checksum of the password in the user
table. ...
Or you can store the cleartext password in the user
table and send a
On Jan 9, 2010, at 11:35 AM, D. Richard Hipp wrote:
On Jan 9, 2010, at 11:29 AM, Ron Aaron wrote:
On Saturday 09 January 2010 18:21:00 D. Richard Hipp wrote:
There is a trade-off.
You can store an cryptographic checksum of the password in the user
table. ...
Or you can store the
On Saturday 09 January 2010 18:35:51 D. Richard Hipp wrote:
I'm not familiar with that algorithm. Can you explain or provide a link?
Do the same thing as at present, in that the client sends the password hashed
and not in cleartext.
The server takes that hashed value and the user name,
On Jan 9, 2010, at 11:04 AM, Ron Aaron wrote:
I didn't see an option, perhaps it's not even on the list of
requests... but
when I look at the 'user' table, the user's password is stored in
cleartext.
Having my fossil file on a shared server, this makes me a bit
nervous. Anyone
who
On Sunday 10 January 2010 00:24:14 D. Richard Hipp wrote:
I have not yet done step (1) on the server that runs www.fossil-
scm.org. I'll do that after additional testing and after you, gentle
readers, have reviewed my changes and informed me that my changes are
free of new security
14 matches
Mail list logo
