Hi Dave,
> It seems to have been lost somewhere along the way, but my original email
> indicated I use a one-way hash of the password (a la crypt(), but there
Yes, I know. As Tomas already noticed, I mixed up encryption and
hashing, though I'm well aware of the differences, and also used MD5 in
m
On Oct 28, Alexander Burger scribed:
> On Wed, Oct 27, 2010 at 04:21:45PM -0400, David N Murray wrote:
>
> Or simply create an account for yourself and analyze the encryption of
> your own password in the client. As the client needs the full
> information, including the encryption keys, you might
Tomas,
just to make it clear (again, as I already wrote this in this thread):
It would b extremely simple to "hash" the passwords. Just call something
like
(native "libcrypto.so" "MD5" '(B . 16) Str (length Str) '(NIL (16)))
in two places (where the passwords are stored, and where they are c
Hi Tomas,
> > But encrypting them creates only an illusion of safety.
> I didn't suggest encrypting them but using hash+salt!
Yes, of course. That's nitpicking. Please excuse that I didn't pay
attention to the terminology.
> 1) the whole discussion about acknowledging that some data are more
>
Hi Alex,
>> I personally have bad experience with people storing passwords in
>> plain text. Technically it might not be an issue (after all I think
>> the wiki doesn't need passwords at all) but it is certainly one of
>> those warning
>
> Thanks as ever for your input, but your argumentation is
Hi Alex,
>> yes, it's all about prevention;-) Storing plain text passwords is no
>> prevention.
>
> But encrypting them creates only an illusion of safety.
I didn't suggest encrypting them but using hash+salt!
> We should not waste our time on irrelevant issues. Whether passwords
> are encrypte
On Wed, Oct 27, 2010 at 04:21:45PM -0400, David N Murray wrote:
> On Oct 27, Tomas Hlavaty scribed:
>
> >
> > not sure if I understand it well but it seems to me that your hash
> > becomes the password. In other words, if I find out the hash, I can log
> > in (e.g. using my own client).
> >
>
>
On Wed, Oct 27, 2010 at 11:29:46PM +0200, Tomas Hlavaty wrote:
> > Well - in a commercial application, not in the Wiki - if he gets hold
> > of the data, then we don't need to worry about the passwords any more
> > :-D
>
> yes, it's all about prevention;-) Storing plain text passwords is no
> pre
Hi all!
I'm fully agree with Alex, in this active discussion about passwords
they sometimes forget about data itself :)
... But here we were
talking about storing plain text passwords in a protected database,
which would get compromised only if the whole database got into evil
hands, which i
Hi Tomas,
> I personally have bad experience with people storing passwords in plain
> text. Technically it might not be an issue (after all I think the wiki
> doesn't need passwords at all) but it is certainly one of those warning
Thanks as ever for your input, but your argumentation is quite
in
Hi Alex,
>> If you use plain text passwords and somebody gets hold of the data,
>> he has all those passwords available for all users instantly. If you
>> don't
>
> Well - in a commercial application, not in the Wiki - if he gets hold
> of the data, then we don't need to worry about the passwords
Hi David,
>> not sure if I understand it well but it seems to me that your hash
>> becomes the password. In other words, if I find out the hash, I can log
>> in (e.g. using my own client).
>>
>
> Yes, I suppose, but the only way I see you getting the hash is:
> a) steal the database
> b) be a MIT
Hi Alex,
>>> Nobody could stop me anyway.
>>
>> What do you mean? You are the provider of the service! I guess
>> there is a missunderstanding somewhere.
>
> I mean as I'm the admin of that machine, I cannot be stopped to access
> the passwords.
You are the provider of the service and as such
Hi Tomas,
> If you use plain text passwords and somebody gets hold of the data, he
> has all those passwords available for all users instantly. If you don't
Well - in a commercial application, not in the Wiki - if he gets hold of
the data, then we don't need to worry about the passwords any more
On Oct 27, Tomas Hlavaty scribed:
>
> not sure if I understand it well but it seems to me that your hash
> becomes the password. In other words, if I find out the hash, I can log
> in (e.g. using my own client).
>
Yes, I suppose, but the only way I see you getting the hash is:
a) steal the datab
On Wed, Oct 27, 2010 at 08:50:51PM +0200, Tomas Hlavaty wrote:
> > Nobody could stop me anyway.
>
> What do you mean? You are the provider of the service! I guess there
> is a missunderstanding somewhere.
I mean as I'm the admin of that machine, I cannot be stopped to access
the passwords. Even
Hi Alex,
>> This is a big flaw. You should not be able ever to find out his
>> password.
>
> Why not?
>
> I could trace the program during execution, for example, to get the
> passwords.
in a sense you are doing exactly this. And your trace log of plain text
passwords goes to the picolisp datab
Hi David,
> In general, I've always designed systems with passwords stored in a
> database as a one-way hash so that if the database gets compromised,
> you're not giving up users' passwords (it's a PITA to tell everyone to
> change their password). I encrypt the passwords in the browser (using
>
Hi Alex and Edwin,
>>> This is a big flaw. =A0You should not be able ever to find out his
>>> password.
>>
>> Why not?
>>
>> Nobody could stop me anyway. I could trace the program during execution,
>> for example, to get the passwords.
>
> oh yes! :D
So you don't lock your house because it's impo
Hello all,
On Wednesday 27 October 2010 16:15:35 Dave wrote:
> (...) I encrypt the passwords in the browser (using the
> same algorithm) and always transmit an encrypted password. There's no
> place to peek. (...)
I believe you mean `I take a hash of password and some salt in the browser and
On Oct 27, Alexander Burger scribed:
>
> Why not?
>
> Nobody could stop me anyway. I could trace the program during execution,
> for example, to get the passwords.
>
Pardon me for jumping in (short time lurker; reading the archives alot).
In general, I've always designed systems with passwords st
On Wed, Oct 27, 2010 at 2:54 PM, Alexander Burger wro=
te:
> Hi Tomas,
>
>> This is a big flaw. =A0You should not be able ever to find out his
>> password.
>
> Why not?
>
> Nobody could stop me anyway. I could trace the program during execution,
> for example, to get the passwords.
oh yes! :D
/e
Hi Tomas,
> This is a big flaw. You should not be able ever to find out his
> password.
Why not?
Nobody could stop me anyway. I could trace the program during execution,
for example, to get the passwords.
Cheers,
- Alex
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Hi Alex,
> You see the advantage in the current case: After Javier forgot his
> password (and started this thread) I sent him his old password in an
> encrypted mail.
This is a big flaw. You should not be able ever to find out his
password.
Cheers,
Tomas
--
UNSUBSCRIBE: mailto:picol...@softwa
Hi Tomas,
> On the other hand, as far as I remember, the "standard" picolisp way of
> storing passwords in plain text and even sending them to the user
> editing dialog is even worse.
No, this is not the case! The passwords do not go to the GUI, and never
leave the server.
Yes, they are stored
Hi Dexen,
>>> Alex, please add a feature to reset the password, as I don't
>>> remember
>>
>> Thinking about it: What would be the best way?
>
> A rather popular aggregator known as Hacker News is using manual password
> reset method.
Interesting!
There is even better way for a wiki. Simply _
Hi Alex,
>> 1. When the user presses reset pass the button on a valid user, generate
>> a random password.
>> 2. Store it in a special field in the User object (rpass?) along
>> with the date of which that random pass was generated (rdate?)
>> 3. Send it to the user in an email like this:
>> Subje
El Wed, 27 Oct 2010 01:00:38 +0800
Boh Yap escribi=C3=B3:
> hi,
>=20
> send 2 emails, the 1st informing that passwd reset is activated and a
> following email will contain the temp. passwd.
>=20
> then send the passwd in the 2nd email. And if the 2nd email does not
> mention an acct name, then its
hi,
send 2 emails, the 1st informing that passwd reset is activated and a
following email will contain the temp. passwd.
then send the passwd in the 2nd email. And if the 2nd email does not
mention an acct name, then its reasonably safe.
2010/10/26 Jos=E9 Romero :
> El Tue, 26 Oct 2010 16:57:1
El Tue, 26 Oct 2010 16:57:10 +0200
Alexander Burger escribi=C3=B3:
> Hi Jos=C3=A9,
>=20
> > 1. When the user presses reset pass the button on a valid user,
> > generate a random password.
> > 2. Store it in a special field in the User object (rpass?) along
> > with the date of which that random pa
Hi José,
> 1. When the user presses reset pass the button on a valid user, generate
> a random password.
> 2. Store it in a special field in the User object (rpass?) along
> with the date of which that random pass was generated (rdate?)
> 3. Send it to the user in an email like this:
> Subject: Pa
El Tue, 26 Oct 2010 14:31:17 +0200
Alexander Burger escribi=C3=B3:
> On Sat, Oct 23, 2010 at 12:18:45AM +0200, Javier wrote:
> > Alex, please add a feature to reset the password, as I don't
> > remember
>=20
> Thinking about it: What would be the best way?
Try this:
1. When the user presses rese
On Tuesday 26 October 2010 14:31:17 you wrote:
> On Sat, Oct 23, 2010 at 12:18:45AM +0200, Javier wrote:
> > Alex, please add a feature to reset the password, as I don't remember
>
> Thinking about it: What would be the best way?
A rather popular aggregator known as Hacker News is using manual pa
On Sat, Oct 23, 2010 at 12:18:45AM +0200, Javier wrote:
> Alex, please add a feature to reset the password, as I don't remember
Thinking about it: What would be the best way?
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Hi Javier,
> Alex, please add a feature to reset the password, as I don't remember
> mine and can't log in the wiki!
Thanks, good idea! Will do that.
Cheers,
- Alex
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Alex, please add a feature to reset the password, as I don't remember
mine and can't log in the wiki!
Thanks in advance.
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
36 matches
Mail list logo
