password policy
-
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???
-
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)
Just a thought: what constitutes a similar password? Okay, we can look at things that are close in terms of characters but there are thousands of sequences that aren't detectable that way. Let's say a user has the following chain of passwords: HunkyD0ry71 Ziggy5tardust72 A1add1nSan373 It's a pretty safe bet that the next one would either be P1nUp573 or D1am0ndD0g574 (depending on whether our user regards Pin Ups as a "proper" Bowie album. There's no way that you're ever going to trap that with software but it's very easy for a human to work out. I guess I'm like most people in my home use in that I use Keepass and never even look at my generated passwords, let alone memorise them (idiot password policies that demand less secure passwords are a complete annoyance here but I'll save that rant for another day). In work-places though, especially if people are working on fixed images or locked-down machines, we're forced into that altogether less secure world where users need a self-made memorable password. This is where highly human-predictable patterns like the Bowie sequence above come into play and also where published restrictions (x-y chars which must include blah, blah and blah) can make it even easier to derive current passwords from old ones. And, let's face it, however many times you tell people to never write their passwords down, you know full well that a search through any office will turn up a fair few scribbled on notebooks and post-its.
-
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???
:-D You did not really believe there was a hash comparator, did you ?
-
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.
raddevus wrote:
Actually, there is a way to generate a strong password without storing it and without having the user memorize a word-based mnemonic
You got a long string that you did not memorize and did not store - in that case, I will start to doubt your ability to produce the same string again. That is something that is kinda required to be used as a password.
raddevus wrote:
Here's all of Shakespeare's sonnets first lines
Not a fan of Shakespeare. So, you already know the length of the string, the pattern, and are assuming English language (yes, it is an English writer, but that does not mean the password has to be). How many possible combinations would there be? xkcd: Password Strength[^]
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
raddevus wrote:
Actually, there is a way to generate a strong password without storing it and without having the user memorize a word-based mnemonic
You got a long string that you did not memorize and did not store - in that case, I will start to doubt your ability to produce the same string again. That is something that is kinda required to be used as a password.
raddevus wrote:
Here's all of Shakespeare's sonnets first lines
Not a fan of Shakespeare. So, you already know the length of the string, the pattern, and are assuming English language (yes, it is an English writer, but that does not mean the password has to be). How many possible combinations would there be? xkcd: Password Strength[^]
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
I think this could go alongside Godwin's Law - the longer an on-line debate about passwords continues, the probability of someone linking to xkcd 936 approaches certainty. Won't somebody think of the horses (and staples)?
-
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!
Cool. I have a file with the very same name. :) That's what they get for making us change passwords every 90 days, unable to reuse the last 24 passwords, and they must be sufficiently gobbledy-gook.
We won't sit down. We won't shut up. We won't go quietly away. YouTube and My Mu[sic], Films and Windows Programs, etc.