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 l
I have updated all of my fossil servers to the latest code that
includes support for the new SHA1 passwords. New precompiled binaries
are available at
http://www.fossil-scm.org/download.html
I have not yet converted passwords to SHA1. Once I do that, if you
have a login, the login wi
I get:
No such document: tip/www/password.wiki
for the link below.
Jeremy
"D. Richard Hipp" wrote:
> A description of current password handling can be seen at
>
> http://www.fossil-scm.org/fossil/doc/tip/www/password.wiki
>
> Please comment and if there are no problems seen, I will comm
On Jan 11, 2010, at 12:21 PM, Tiago Dionizio wrote:
> Hi Richard,
>
> Because the file was checked-in in the experimental branch, it is
> not accessible through that url.
>
It was before Jeremy added http://www.fossil-scm.org/fossil/vinfo/1bf6cf832d
on the trunk. But regardless, you can a
Hi Richard,
Because the file was checked-in in the experimental branch, it is not
accessible through that url.
Regards,
Tiago
On Mon, Jan 11, 2010 at 3:10 PM, D. Richard Hipp wrote:
> A description of current password handling can be seen at
>
> http://www.fossil-scm.org/fossil/doc/tip/ww
A description of current password handling can be seen at
http://www.fossil-scm.org/fossil/doc/tip/www/password.wiki
Please comment and if there are no problems seen, I will commit the
latest changes to the trunk and put new binaries on the website.
D. Richard Hipp
d...@hwaci.com
_
It's been quite a while since I looked into the details, but I do know
that the SyncML (or OMA DM as it is known now) protocol provide
authentication with HTTP as one of the available transport protocols.
I think it uses a shared secret. Might be worth looking into. See
http://member.openmobilealli
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.
Anot
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. Th
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 p
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
ma
On Sunday 10 January 2010 13:32:31 Twylite wrote:
> Hi,
...
> Cryptographically this is equivalent to sending a cleartext password
> over HTTP and storing a hash of the password.
Yes, you are correct that from the standpoint of someone intercepting wire
traffic, such a person can still log in. H
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 i
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 boo-b
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. Anyon
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, hashe
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 yo
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
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 ano
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. Anyon
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 wrote:
> I didn't see an option, perhaps it's not even on the list of re
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
22 matches
Mail list logo
