h a l f b a k e r y"More like a cross between an onion, a golf ball, and a roman multi-tiered arched aquaduct."
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,
|
|
|
(not my idea, It was explained to me by a friend)
The basic idea here is a password for a computer that seems like an ordinary password, but when an incorrect password is entered, the current password for the computer is changed to the incorrect password that was just entered. This effectively guards
against brute force attacks, because the actual password will always be one step behind the brute forcing program. It will also alert the user that someone has tried to hack their system, when they first enter the correct password, it will register as wrong, and they will have to enter it again to gain access to their computer.
Please log in.
If you're not logged in,
you can see what this page
looks like, but you will
not be able to add anything.
Destination URL.
E.g., https://www.coffee.com/
Description (displayed with the short name and URL.)
|
| |
First of all, this means I can hack into your
computer by entering any (wrong) password twice. |
|
| |
It also means that, if I try to hack in once with a
wrong password, you won't know the new
password to your own computer. |
|
| |
Apart from those two flaws, it's faultless. |
|
| |
As with most such, this is security through obscurity. As long as the system isn't known, it might work, as soon as it's public knowledge, it's easily breakable. |
|
| |
1) That would fall at the first post to anyone using the time-travelling computer or would that be the second post? |
|
| |
2)Alternatively, how about a system with ten billion hard to guess passwords that users can get by making a memorable sentence...sounds strangely familiar... |
|
| |
I was about to bone this, but then I thought - what if the password reset (a) were temporary and (b) kicked in only when a brute force attack seemed to be in progress and (c) kicked out again when it detected an attempt to game it? |
|
| |
So, if you manually type "rubbish" twice into my laptop, then my password remains as it was and you haven't cracked it. |
|
| |
However, if you (or a script) hit my laptop more than [some semi-random threshold] times during a period of, say, one minute, then my password gets reset to a random recently-attempted password (which may or may not be my original password) for the next [semi random period of time not exceeding, say, five minutes]. |
|
| |
Furthermore, if this second-guessing algorithm detects someone attempting the *same* wrong password more than [some semi-random threshold] times, it reverts the password to my original one. |
|
| |
Then we could add some fretwork and a cuckoo clock. |
|
| |
If the system can detect that a brute force attack is ongoing, it can be set not to accept the password even if it comes up. |
|
| |
Heck, if it can be set to do that, then it could be set to say something like 'the password is the current user's credit card account number' or some kind of offense as defense strategy. Or, have it accessible into a fake 'honeypot' system, in which keystrokes and clicks are then recorded. That's be kinda fun. |
|
| |
A well-implemented password system using non-public salted hashes is pretty tough to crack as-is. If non-salted hashes are used and the hash table is public or leaked, a brute-force attack basically runs a rainbow-table lookup against the hash table and returns a list of passwords which match hashes in the table. A delay as posted by [bigsleep] works against someone repeatedly trying to gain access through the normal login process, but fails entirely when the password can be cracked before it is entered. |
|
| |
More appropriate may be to track the IP of everyone logging in, and throw up an IP block if several accounts are accessed from the same IP in a very short time. This won't catch attacks targeted to an individual, but it should stop attacks targeted to a service. |
|
| |
//A well-implemented password system using non-public salted hashes is pretty tough to crack as-is.// |
|
| |
The salts are generally considered to be as public as the password hashes. |
|
| |
That is, if you can store the salts securely, then why don't you just store the passwords securely? |
|
| |
If we're going to all this trouble to have the computer
change a password after every hit when it detects a brute
force attack, why not just have it go into lockdown until
the attack is over? I mean, these things don't typically last
very long, do they? Just make it so there is no password
and no access and nobody can get in until the assault is
over. |
|
| |
doing that requires the ability to tell when a brute force attack is happening, and when it has stopped. My idea, however, just requires that nobody know about it to be secure. |
|
| |
For a networking situation and system to look for brute force attempts and shuts down services in response, especially to legit users (people who have working u/p) is making itself an easy target for DOS attacks. All you need to deny all users access is to launch a brute force password attempt which takes almost nothing on the part of the hacker. |
|
| |
Okay, I understand it a bit better now. |
|
| |
[Loris], a system which makes its hash table publicly available is not one that I'd call well-implemented. That said, even if the salt is leaked along with the hash, there is still the issue of building a custom rainbow table for the given salt. Further, a system which uses a salt particular to each account (let's say the salt is the raw hash of the account name), the rainbow table must be built up for each account. While none of these methods make the crack process any more -difficult-, they make it much more computationally expensive. |
|
| |
Essentially speaking, any situation where a password is not derived by an entirely random process will be more vulnerable than a system where there is any sort of pattern. Any password system where repetition of a random password, at any point in the process, be it on the first attempt or an attempt after the first attempt will be far more vulnerable than a system where the password is fixed on a random, long, and uncommon string of characters. |
|
| |
[WcW] // any situation where a password is not
derived by an entirely random process will be more
vulnerable than a system where there is any sort
of pattern// Actually this isn't true unless the
pattern is known. (The following is distilled from
Steve Gibson's "Security Now" podcast) If my
password is 26 "a"s in a row, it is not random, but
if you don't know that it isn't random, then you
can start guessing, usually starting with a
dictionary attack, then maybe dictionary with
standard substitutions, (a > @, O > 0, etc), but if
those and similar attempts fail, you will have to
guess randomly. At that point, as long as you
avoid the common traps, only the length of the
password matters and
"aaaaaaaaaaaaaaaaaaaaaaaaaa" will take a long time
to break if attacked randomly and way longer than
what seems like a good password like "3Y2b^l"
which has a lot more randomness. |
|
| |
Would it not be simpler if everyone in the whole
world agreed to use the same usernames and the
same password, for everything? |
|
| |
That way, the hackers would not be able to hack
selectively into your PayPal account and steal
your millions, because 99,999 times out of 100,000
they'd wind up in the account of some loser with
no money. |
|
| |
Good idea [MaxB]. What username and password do you
use? We will all change over to the same ones once you
tell us. |
|
| |
billygatesgruff, thunderbox404. Just whatever you
do, don't keep it secret. |
|
| |