h a l f b a k e r yRight twice a day.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Please log in.
Before you can vote, you need to register.
Please log in or create an account.
|
The idea is simple: before the system accepts your correct
password, you must first attempt to log in using a
specified
"knock" password. The system will reject this first
password
in the normal fashion, and to all outward appearances it
would simply seem that an incorrect password had been
typed in. However, the system would detect the "knock"
password, then accept the actual password on the next
attempt.
The primary advantage of doing this is that it would stop
brute force attacks cold. Even if a cracker knew about
this
security method, it would immediately square the search
space for potential passwords. And it would be trivial for
a
system to detect the same incorrect password being
repeatedly attempted within a given amount of time, and
cut off access or alert an administrator.
Also, attacks on the password hash itself, such as rainbow
table attacks, would be made much more difficult. Even
if
a cracker somehow got a list of all of the users and
passwords on a system, he wouldn't be able to do anything
with it without knowing the "knock" password. And while
he
might be able to brute force this, repeated entry and
refusal
of a correct password would trigger an alert condition as
mentioned above.
Lastly, even if somebody managed to compromise the
username, password, and "knock" password, security could
be restored systemwide by simply changing the "knock"
password. Since this password would be set by the system
administrator rather than the users, it could be stored in a
more difficult to compromise manner than the regular
password database—perhaps even hardcoded into the
authentication program itself. Of course, since it must be
shared with the users (although it could be set on a per-
user
basis), it would be potentially easy to compromise by non-
technical methods. However, the requirement to take the
additional step to do so would complicate the attack
significantly, particularly in the case of automated botnet
attacks.
knockd
http://www.zeroflux.org/projects/knock
does at advertised [fho, Feb 02 2012]
xkcd...
http://xkcd.com/936/
...on passwords. [DrBob, Feb 02 2012]
Double Secret Probation
http://www.youtube....watch?v=Y0cF2piwjYQ
[normzone, Feb 03 2012]
[link]
|
| |
There's many ad hoc methods of increasing security against standard attacks. This method topologically simply increases password length. Though having the first bit set by sysadmin sounds interesting. |
|
| |
At [FlyingToaster] says, this just increases password length. Also, having the system define a user's password is common practice. My password is automatically changed to a new, random, 9-letter password every month. The solution proposed here just adds complexity, which is often confused with adding security. |
|
| |
It might seem like it just increases the length of the
password, but it really does more than that. You could
only mount an effective brute force attack if you already
know one or the other of the two passwords. But
entering. and having the system reject, the same
password repeatedly is easily detectable, even if you only
have the hash of the entered password to compare with
and not the actual password itself. Just making the
password longer only still creates a single hash, so two
different password attempts can't be compared for
similarity. |
|
| |
[hippo], that sounds like a total pain for the users, and
doesn't really do much for security (in fact, it lessens it,
because users will invariably write their passwords down
and leave them in insecure places). Wouldn't it be easier
to have your own personal password that doesn't change
regularly (one that you have memorized), and to be
issued a rotating additional password every month that's
simply, say, a
dictionary word? It could even be just a four
digit numeric code, and it would add basically the same
amount of additional security. Since having to put in two
separate passwords severely hampers brute force
attacks, it doesn't need to be an overly complicated
password. Just rotate it every month or so, and you'll be
fine. And even if users write down the "knock" password,
by having part of the password be something they have
memorized, it doesn't do an attacker any good to find it. |
|
| |
Of course, all of these benefits could be realized by
simply requiring two passwords to log in: one the user
has memorized, and one assigned by the sysadmin. I'm
willing to concede that the ruse of entering an "incorrect"
password followed by a "correct" one only provides a
marginal bit of security through obscurity (and hence, not
really any security at all), but I still think the basic idea
of having two passwords is sound. |
|
| |
two sequentially entered passwords = one long password. |
|
| |
The only difference is that you've added <CR> and pause(if applicable) to the list of characters. |
|
| |
No, because with two passwords, one can be changed by
the sysadmin without affecting the other, and can
potentially be shared by all users. With one long
password, you can't just change half of it without knowing
the other half. |
|
| |
While they may be cryptographically equivalent, two
passwords and one long password are functionally quite
different. |
|
| |
The "incorrect/correct" label isn't what you mean since neither password is incorrect. |
|
| |
The admin-set/user-set passwords, as I said, sounds interesting but, for the third time, it doesn't provide any more security against a brute-force attack than an extended length single password. The advantage would be against social-hacking in general. |
|
| |
actually this method exists and is more or less widely known.
[see link] |
|
| |
the advantage is that the service isn't open to the outside
and therefore can't be spotted by an attacker |
|
| |
Is it mathematically harder to brute force? No. |
|
| |
Does it potentially make it easier to detect and stop brute
force attacks? Yes. |
|
| |
Does it therefore "provide any more security against a
brute-force attack than an extended length single
password"? I would have to say it does. |
|
| |
//Does it potentially make it easier to detect and stop brute force attacks? Yes. // No. |
|
| |
Having your detection software look for non sys-password repetition is different from looking for non-longer-user-password repetition in what manner ? |
|
| |
Because looking for the /same/ password being entered
over and over is much easier than looking for /similar/
passwords being entered serially (and if you only have
access to the encrypted version of the password, or a
hash of it, comparing similar passwords is impossible). If
you detect that someone (or a group of someones) keeps
entering the same correct system password, but different
user passwords each time, it's trivial to either block
further connections, or change the system password and
render the entire attack fruitless. |
|
| |
The system could be configured to automatically change
the system password (and notify users) after a given
number of total attempts where the system password is
correct and the user password is wrong. So even if an
attacker is just trying both passwords randomly, he could
exhaust the entire key space without discovering either
password, unless he happens to get really lucky and,
within the first, say, 25 tries that he happens to randomly
get the system password correct, he also randomly gets
the user password correct. Meaning that you could
search through every possible password, and still only
have a minute chance of finding the correct one. A
distributed brute force attack would be effectively
impossible this way. |
|
| |
Let's take a really simple example. Imagine your user
password is known to be a six letter lowercase English
word, and the system password is four numeric
characters. Assuming roughly 15,000 six letter words,
that yields 15,000 * 10^4, or 150,000,000 combinations.
That's pretty easy to brute force. But, if you change the
system password after each 25 correct guesses but failed
logins, such an attack would succeed an average of 1 out
of (15,000 / 25 = 600) times*. The only way to attack
such a password system would be to repeatedly throw
random keys at it until you happen to luck out, which
would take, on average, about as long as brute forcing a
system with a key space of 90,000,000,000 potential
passwords. |
|
| |
In sum, even with a password policy yielding passwords
that would be trivially easy to brute force, you could still
have security comparable to a system with a much more
complicated and onerous password scheme. |
|
| |
*Actually, it's probably slightly less, because there's a
chance that the new system password could be within the
as yet untried part of the key space. |
|
| |
// (and notify users)// How? |
|
| |
Just curious, but you frequently have to be able to log in to get notifications. |
|
| |
Alternate email address, SMS, carrier pigeon, singing
telegram, smoke signals, coded message on highway
billboards... |
|
| |
So the same thing as saying "OK, everybody change the first 4 characters of their password to 1234". |
|
| |
//The system could be configured to automatically change the system password (and notify users) after a given number of total attempts where the system password is correct and the user password is wrong. // |
|
| |
It seems like it should be pretty easy to have some kind of rolling password algorithm for the system reset which is known to the legitimate users but hard to guess for the attacker, so then the only communication that would be required would be 'login attempt trials exceeded, next system password chosen' or somesuch. |
|
| |
//Alternate email address, SMS, carrier pigeon, singing telegram, smoke signals, coded message on highway billboards...// |
|
| |
So you've weakened the first half of your password to the weakest protection on someone's alternate contact. |
|
| |
//So the same thing as saying "OK, everybody change the
first 4 characters of their password to 1234".// |
|
| |
Sure. In the same way that saying "OK, everybody pick a
really good password and keep it safe" is the same as
enforcing a good security policy. |
|
| |
Why bother locking your car? Just put a sign on the
dashboard saying "This car is hard to break into." Exactly
the same thing. |
|
| |
Why not go for dodecatuple secret authentication?
<Dean Vernon> Whenever a fire alarm is pulled, Robot House. Whenever the campus liquor store is looted, Robot House. Whenever a human corpse is desecrated- </DV> |
|
| |
Don't computer systems lock you out for an hour after three failed passwords anymore? I thought that was pretty good defense against brute force password cracking. A bit of a pain if someone tried to hack your account and now YOU can't get in for an hour, but it's very secure. |
|
| |
A bone for trying to make me learn yet another *#@&$*$%* password. Got too many of them things already, dagnabbit! |
|
| |
Sorry, just picking. No bone, but I don't think it would be any more secure and it would dramatically increase the number of people bugging admin because they forgot one of the two passwords. |
|
| |