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).
Yes, I
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 encrypted
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 quite
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 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
my
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:
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
On Wed, Oct 27, 2010 at 2:54 PM, Alexander Burger a...@software-lab.de 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
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 stored
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
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 impossible to make it
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
the
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 database.
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 if
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 database
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
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 users trust
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 MITM over
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 any
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
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
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
prevention.
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
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
El Tue, 26 Oct 2010 14:31:17 +0200
Alexander Burger a...@software-lab.de 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
El Tue, 26 Oct 2010 16:57:10 +0200
Alexander Burger a...@software-lab.de 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
El Wed, 27 Oct 2010 01:00:38 +0800
Boh Yap bhy...@gmail.com 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
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:
Subject:
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 in
29 matches
Mail list logo
