password policy
-
Couldn't it depend on the encryption? I haven't tested it, but if you encrypt two very similar passwords using the same algoritm, could it be possible that the two encrypted passwords also were quite similar (and perhaps even comparable)? :confused:
Anything that is unrelated to elephants is irrelephant
Anonymous
-----
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-----
I'd just like a chance to prove that money can't make me happy.
Me, all the timeIf an encryption would produce the same output for the same input it would be useless...(breakable in seconds)
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
-
If an encryption would produce the same output for the same input it would be useless...(breakable in seconds)
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
Perhaps - just an idea... :sigh:
Anything that is unrelated to elephants is irrelephant
Anonymous
-----
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-----
I'd just like a chance to prove that money can't make me happy.
Me, all the time -
Well, we don't need to re-enter the old password and assuming it does not save it in clear text, how is it comparing the old (encrypted) password to the new (encrypted) one? example: OLD password text: god_123 encryped: &#HDSW NEW password text: god_124 encrypted: )#@^Y@ it should not save the text version and it should not be able to compare the encrypted version, right? [EDIT]We are "logged in" though, (LDAP), but I'm assuming, equally, the password is not saved in memory either...[/EDIT]
V.
(MQOTD rules and previous solutions)
From OpenLDAP Software 2.4 Administrator's Guide: Security Considerations[^]:
Quote:
LDAP passwords are normally stored in the userPassword attribute. RFC4519 specifies that passwords are not stored in encrypted (or hashed) form. This allows a wide range of password-based authentication mechanisms, such as DIGEST-MD5 to be used. This is also the most interoperable storage scheme. However, it may be desirable to store a hash of password instead.
-
Couldn't it depend on the encryption? I haven't tested it, but if you encrypt two very similar passwords using the same algoritm, could it be possible that the two encrypted passwords also were quite similar (and perhaps even comparable)? :confused:
Anything that is unrelated to elephants is irrelephant
Anonymous
-----
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-----
I'd just like a chance to prove that money can't make me happy.
Me, all the timeTo compare similarity between passwords you need to know: 1) The characters which are present in the password; 2) The sequence of such characters. Whcih amounts to knowing the password itself, even if a mangled version.
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
-
To compare similarity between passwords you need to know: 1) The characters which are present in the password; 2) The sequence of such characters. Whcih amounts to knowing the password itself, even if a mangled version.
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
Well, not necessarily. If the encryption worked like this (just an example of course): Pass1word => #¤%"AsdfY2g&Po*qQs Pass2word => #¤%"Asdf7Xg&Po*qQs it would still be comparable even encrypted... You only need to know how much that is changed - not WHAT EXACTLY is changed... :doh:
Anything that is unrelated to elephants is irrelephant
Anonymous
-----
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-----
I'd just like a chance to prove that money can't make me happy.
Me, all the time -
LDAP stores password in history using HASH, no two way encryption there... The only password may be stored as cleartext is the current one...
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
All of my passwords at work are stored as plain text. ... In a text file named "passwords.txt" on my desktop.
I wanna be a eunuchs developer! Pass me a bread knife!
-
LDAP stores password in history using HASH, no two way encryption there... The only password may be stored as cleartext is the current one...
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
He hasn't said what password system this is though.
-
He hasn't said what password system this is though.
-
From OpenLDAP Software 2.4 Administrator's Guide: Security Considerations[^]:
Quote:
LDAP passwords are normally stored in the userPassword attribute. RFC4519 specifies that passwords are not stored in encrypted (or hashed) form. This allows a wide range of password-based authentication mechanisms, such as DIGEST-MD5 to be used. This is also the most interoperable storage scheme. However, it may be desirable to store a hash of password instead.
Jochen Arndt wrote:
RFC4519 specifies that passwords are not stored in encrypted (or hashed) form.
:wtf: And this is secure ... how? :confused: I thought the current "safest" thing to do is to have salted hashes, right?
V.
(MQOTD rules and previous solutions)
-
Had the same system at my last employer, and I doubted then that it was as secure as they thought. But hey ho, IT department were the experts, and did not like being challenged.
-
All of my passwords at work are stored as plain text. ... In a text file named "passwords.txt" on my desktop.
I wanna be a eunuchs developer! Pass me a bread knife!
Same with me - I have 9 pre-created passwords (we have 8 stored in history) stored as plain text...
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
-
Jochen Arndt wrote:
RFC4519 specifies that passwords are not stored in encrypted (or hashed) form.
:wtf: And this is secure ... how? :confused: I thought the current "safest" thing to do is to have salted hashes, right?
V.
(MQOTD rules and previous solutions)
V. wrote:
And this is secure ... how?
Secure as the access to the server which can be restricted by
- Using secure communication (SSL, TLS)
- Restricting network access (firewall)
- Restricting login (remote and physical)
- Restricting physical access
- Using a dedicated LDAP system without any other services
If it is only used for local authentication the server should also have no internet connection. If I would have to decide between encrypted passwords and the ability to check for similar passwords I would choose the first option.
-
V. wrote:
And this is secure ... how?
Secure as the access to the server which can be restricted by
- Using secure communication (SSL, TLS)
- Restricting network access (firewall)
- Restricting login (remote and physical)
- Restricting physical access
- Using a dedicated LDAP system without any other services
If it is only used for local authentication the server should also have no internet connection. If I would have to decide between encrypted passwords and the ability to check for similar passwords I would choose the first option.
Not so, LDAP requires authenticated but not privileged access on client hosts. It's about as secure as tossing a passwords list into the NETLOGON folder. If it's not configured correctly (ie proper permissions added to the password field), literally any domain machine can get those passwords, apparently in plain text.
Jochen Arndt wrote:
If I would have to decide between encrypted passwords and the ability to check for similar passwords I would choose the first option.
Choose neither. Encryption is reversible by definition; go with a salted, unpadded hash.
"There are three kinds of lies: lies, damned lies and statistics." - Benjamin Disraeli
-
So we have a new password policy here at work and one of the rules is you cannot change it into something that is too similar to the previous one. Question: How is that determined since the hashing value should change significantly if you change just one letter ?
V.
(MQOTD rules and previous solutions)
Goldman Sachs employs this type of password policy. Most major corporations do. I'm sure other companies large and small do something similar. The idea is that a lot of people keep the same portions of their password the same and just change out incremental sections whenever they have to change the password (usually every 2-3 months). In theory, this can be hacked very easily.
-
So we have a new password policy here at work and one of the rules is you cannot change it into something that is too similar to the previous one. Question: How is that determined since the hashing value should change significantly if you change just one letter ?
V.
(MQOTD rules and previous solutions)
V. wrote:
you cannot change it into something that is too similar to the previous one.
Have you tested it? Maybe it's just a vapor-policy. ;)
V. wrote:
How is that determined since the hashing value should change significantly if you change just one letter ?
If they are truly hashing, then they can't. If the policy actually works, then they are encrypting, not hashing. Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
-
:laugh: Ha ha, no. They had an attack here at work last year and since then we're forced to use increased security policies, but we're doubting the effect of some of the measures...
V.
(MQOTD rules and previous solutions)
In Active Directory, there is a GPO that you can activate to force passwords storage in plain text. I cannot imagine any situation where that would be suitable, though. On the other hand, the security breach concerning passwords must not be observed only through their storage on the servers; humans themselves may represent a non negligeable risk when it comes to password security (writing them down on a sticky note, always following the same pattern, references to family, friends, pets, etc.).
Loneliness and cheeseburgers are a dangerous mix.
-
So we have a new password policy here at work and one of the rules is you cannot change it into something that is too similar to the previous one. Question: How is that determined since the hashing value should change significantly if you change just one letter ?
V.
(MQOTD rules and previous solutions)
V. wrote:
Question: How is that determined since the hashing value should change significantly if you change just one letter ?
That is a fantastic question, full of insight. Very interesting, since they are not supposed to know what your password is, but only the hash. :thumbsup::thumbsup::thumbsup::thumbsup: I've written quite a bit about passwords and am on a conquest to destroy but that's for another time : Destroy All Passwords: Never Memorize A Password Again[^]
My book, Launch Your Android App, is available at Amazon.com.
-
When resetting your password you usually need to enter your existing password so the code has both and can compare. If you're not asking for the existing password then the system either stores passwords in plain text or in encrypted form.
F-ES Sitecore wrote:
your password you usually need to enter your existing password
Very good explanation. That must be it. Thanks for reminding us of that. I forgot that you have to re-enter your old one.
My book, Launch Your Android App, is available at Amazon.com.
-
Well, we don't need to re-enter the old password and assuming it does not save it in clear text, how is it comparing the old (encrypted) password to the new (encrypted) one? example: OLD password text: god_123 encryped: &#HDSW NEW password text: god_124 encrypted: )#@^Y@ it should not save the text version and it should not be able to compare the encrypted version, right? [EDIT]We are "logged in" though, (LDAP), but I'm assuming, equally, the password is not saved in memory either...[/EDIT]
V.
(MQOTD rules and previous solutions)
If they have enough hashing capacity (trivial if SHA*, needs a cluster if using a slow hash), they could mutate your new password making every possible 1 character addition/subtraction/substitution and see if any of them match the old hash.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
-
Eddy Vluggen wrote:
An encrypted password is as bad as a plaintext one.
Agreed. Also any memorized password has an inherent weakness in that it can be (and has been) memorized by a human. Passwords should be so strong that they cannot be memorized. It's possible. :)
My book, Launch Your Android App, is available at Amazon.com.
