password policy
-
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.
-
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.
Without memorization, you'd need to keep a clear-text version around. I don't think it is possible to extract it from my mind, so feels rather secure there. The fact that something can be memorized does not make it a weak password.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
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)
-
Without memorization, you'd need to keep a clear-text version around. I don't think it is possible to extract it from my mind, so feels rather secure there. The fact that something can be memorized does not make it a weak password.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
Hyperbole is my favorite of all inventions and must be implemented at all times. :) The point is that when you use a mnemonic then it is based upon words. Words are patterns and patterns can be more easily cracked than non-patterns. What you need is a fully randomized pattern which is strong and less crackable than a weak pattern that you've memorized. Your password itself should be a hash which is so long you cannot memorize it. (Which is hyperbole also, since Daniel Tammet memorized 22,514 digits of pi and recited them[^]). :)
My book, Launch Your Android App, is available at Amazon.com.
-
Hyperbole is my favorite of all inventions and must be implemented at all times. :) The point is that when you use a mnemonic then it is based upon words. Words are patterns and patterns can be more easily cracked than non-patterns. What you need is a fully randomized pattern which is strong and less crackable than a weak pattern that you've memorized. Your password itself should be a hash which is so long you cannot memorize it. (Which is hyperbole also, since Daniel Tammet memorized 22,514 digits of pi and recited them[^]). :)
My book, Launch Your Android App, is available at Amazon.com.
raddevus wrote:
What you need is a fully randomized pattern which is strong and less crackable than a weak pattern that you've memorized.
Again, that idea is wrong. A non-memorizable password needs to be stored. Yes, words are patterns, but that knowledge isn't going to help much in determining my password. I'll give you another clue; it is based on a single line of a poem, 33 characters.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
raddevus wrote:
What you need is a fully randomized pattern which is strong and less crackable than a weak pattern that you've memorized.
Again, that idea is wrong. A non-memorizable password needs to be stored. Yes, words are patterns, but that knowledge isn't going to help much in determining my password. I'll give you another clue; it is based on a single line of a poem, 33 characters.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
Eddy Vluggen wrote:
Again, that idea is wrong.
Brrrr....there's a cold wind a blowin'. "Wrong" is such a cold harsh word. It makes me feel like I might not be right. :-D Actually, there is a way to generate a strong password without storing it and without having the user memorize a word-based mnemonic. And, I'm guessing that your poem is Milton's Paradise Lost, right? Here's all of Shakespeare's sonnets first lines so I'm generating your password off of these now: Shakespeare's Sonnets- first lines[^] :laugh:
My book, Launch Your Android App, is available at Amazon.com.
-
Really? Rickrolling? You are going to stoop that low? A*******.
What do you get when you cross a joke with a rhetorical question? The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism. Do questions with multiple question marks annoy you???
