Such password dialogs could just let you type your best effort, and they could use the things you type to inform the guessing process; you could fat-finger a character or two, and it would just take a moment longer to log in as it uses the accurate parts of the data to make educated guesses of the password. For old encrypted files, for example, I often don't remember which password or which combination of passwords I might have used, but I can provide all the important bits and a smart program could easily guess the right combination.
Here's a recent research paper on the topic: pASSWORD tYPOS and How to Correct them Securely - http://www.ieee-security.org/TC/SP2016/papers/0824a799.pdf
As the other commenter said, there's nothing you can do to prevent brute forcing. What you can do, is have a very expensive KDF. So for every password you enter the wallet will take a very long time to 'unlock', which is basically the process of deriving the key from the input.
'Expensive KDF' sounds cryptic, but often just having some memory/CPU requirements for an instance of the KDF should suffice.
Fun fact: There is a reason why when you enter a wrong password for `su` or `sudo` it seems to take longer to throw the wrong password dialogue than to log you in. That's because the password authentication module (called PAM) artificially delays you to prevent brute forcing. You can go and change it if you want. (I would discourage it)
Of course, this won't stop everyone. One can just put the harddrive in a different computer to get the hash of the password and crack it within a day with proper resources. This is the problem with trying to 'stop' bruteforcing at the input level. You must already asssume the attacker has the hash, then the difficulty must be determined. That's the point of people arguing about password hashes (for fun, of course)
This part. I misunderstood the comment. I thought by 'limited brute forcing support' they meant to limit the brute forcing process. The sibling comment also thought the same thing so I didn't doubt it.
I could be thinking the wrong space though I don't know what Siacoin is or KDF.
edit: after reading...
>If you’re not familiar with Siacoin, it’s a cryptocurrency that allows you to rent out your spare hard disk space or buy space from others.
Interesting not sure I'd do it, what scale you need for this to be worth something as a leasee (leaser?)
That was pretty cool that distance between keys... ahh automation me like, parse out the function/tasks write it out, then let the computer do its magic. Batch processing yeahhhhhhh
For anyone interested in a little more detail: Bitcoin and every decentralized cryptocurrency operates on the concept of a blockchain, which is synchronized to every user (and regularly appended to). Most cryptocurrency blockchains effectively contain a list of (hashes of) public keys known as addresses and currency amounts. You own some currency if you know the private key corresponding to an amount listed in the blockchain, and using that private key you can sign a transaction to send the amount associated with it to another address. (That's the easy half of how Bitcoin and friends work. The other half is the innovative part about getting everyone to agree on the same blockchain even when people create conflicting transactions attempting to double-spend the same money. This involves continuous proof-of-work mining generally. It's not super relevant to anything in OP's post though.)
The user in the OP post who had their Siacoin stolen was using a system (often called a "brain wallet") where their private key was generated from a 29-word phrase. Anyone who knew the 29-word phrase could use that to generate the private key and then create a transaction to steal the currency associated with it. If you almost know the 29-word phrase, then you could brute-force it by repeatedly modifying the phrase, generating the private key, and then looking at your copy of the blockchain to see if that private key had any currency associated with it. (Well, actually the brain wallet system uses a checksum like credit card numbers do, so most invalid 29-word phrases just fail the checksum check and don't need to bother checking the blockchain itself, but that doesn't really impact anything about this process.)
It had 1,000 BTC in it! He had received them from a generous Bitcoin contributor in the early days who said "here you go, hold on to it, it will be worth something someday."
I still give him a hard time about his $3 million USD mistake...
If thats the game there are higher value address to try.
Luckily, that library only cares that you get the first three letters of each word correct, so we can update the word to 'tonsil' or 'tongue' without breaking compatibility.
Filtering the list to require a minimum edit distance of 2 or 3 would be quite easy, too!
I wonder what the original process was?
My application was pass phrases to be read over the phone, but it seems generally useful whenever you want to avoid confusing two words in the set.
A wise wife tagged and jagged and nagged
Her aptitude had altitude to push the lush
He bore the brunt with a grunt and tonic
His music was ionic sonic
Their topic too toxic to adapt
And they, too adept to adopt
First of all, let's look at something: the burden of memorizing 29 words was SO great, that despite carefully writing it down and double-checking it, the user failed to memorize it or even come close: after trying 500 times, they could not tell that ionic was a different word from tonic. No doubt they had looked at each handwritten word very carefully during the 500 attempts, but just could not do it. By the way, if you write the word ionic down in your own handwriting, you could easily see that it might look exactly like your own handwritten tonic.
There is something else about these 29 words. You can find the number of bits of entropy in a dictionary you'd pick one word from at random by taking the log2 of the number of entries. (In a pinch you do log 2 by taking the log and dividing by the log of 2). That shows that 1626 words (the number of entries in the dictionary) have 10 bits of entropy.
So by making the user "remember" (write down) 29 such words, you are making them memorize (write down) 290 bits of entropy.
2^290 is 1.9892929e+87. There are about 10^80 atoms in the ENTIRE universe (a hundred billion galaxies with a hundred billion stars each). You'd have to get every atom in our entire universe -- every planet's every atom, every sun's, every black hole's, every one of the atoms anywhere in the world, to try 10,000,000 operations each, before you got an answer.
That is WAY too much.
But despite having such an incredible amount of extra information in there (base-64 encoding 290 bits would take 48 characters - six bits per character), it does not contain enough of a checksum to correct against a single transcription error.
So this is a great example of a solution that is very user-hostile: so long that the user is forced to write it down, but despite its length so fragile that it does not contain any help against any amount of corruption. And very clearly, the longer it is, the greater the possibility of user error: could you hand-write an entire Dickens novel without a single error anywhere for example? What about a 12-character alphanumeric password? So the latter is stronger than the former! The latter is a better password.
I am not sure what kind of passwords would have redundancy built-in (so that a slightly wrong version would be corrected and accepted) but this would be a good time to find out.
One last thing. Does anyone know how long it takes to try a combination? I'm surprised that the blog poster went through the trouble of finding Levenshtein distance, since I would think from a coding standpoint it would be faster to code trying all 1625 other possibilities for the 1st word (leaving the rest unchanged), trying the other 1625 possibilities for the 2nd word, and so forth. Since there are 29 words this is just 47125 possibilities in total which doesn't seem like it's that many. (Then again, some 'treasure hunter' the blog poster was "competing with" might have had that script running already when the blog poster got there first!)
It's been like that for almost 2 years now, and while 29 is a lot, you aren't going to memorize 17 words either.
The checksum is 6 bytes, and a laptop can verify maybe 100,000 tries per second. So checking for a mistake of 1 word out of 29 will take you maybe 0.5 seconds. 2 words will take 6.5 hours.
If you find one that matches the checksum, it would take maybe 30 minutes on an SSD to scan the blockchain and realize that it's the wrong seed even though the checksum is correct.
But at 6 bytes of checksum, you'd be unlikely to bump into an incorrect but valid seed having just 2 words incorrect.
These seeds are used precisely because they are easier to distinguish than alphanumeric randomness. In this case, 'ionic' and 'tonic' ended up being an unlucky word pair, but we will swap out the word 'tonic' for 'tonsil' I think and that should fix the confusion. (The library only reads the first three characters, so there will be no compatibility issues with this change)
While not the same, I'm reminded of the issue with etherium addresses where they've (after initially having no extra checking) started using mixed case to provide a checksum to detect incorrect entries. Otherwise, it's really easy to send coins to a very slightly different address due to a typo.
With Saicoin, it seems like just adding 1 more word could allow correction of mistakes like these. (And you'd end up with a round 30 words :).
 like these - https://en.wikipedia.org/wiki/Comparison_of_archive_formats#...
In a pinch it's easier to reason that since 2^10 = 1024, 2^11 = 2048, and 1626 lies between those two numbers, log_2 1626 is a bit more than 10.
Memorizing powers of two is useful for lots of quick mental estimation!
We added a checksum though and then grabbed 256 bits instead of 128, so the numerical alignment no longer applies sadly.
Good luck sir.
Posting data to a remote system, with the clear intent of taking a thing of value from another person without permission. Perhaps it falls between the cracks, but I'd be reasonably surprised if it doesn't come under this or another similar act.
"If someone figures it out, I will send you free sias"
I'd call that a clear invitation/authorization for anyone to try to crack his passphrase.
It's like if you find someone's (real) wallet, and you pick it up and contact the owner to ask where to drop it off. Rather than leaving it there and just telling the owner what street corner it's on.
I'm sure you could have a pretty good argument in court if they went after you using CFAA. Other theft and fraud laws might cover it without issue though, just saying CFAA might not be the right choice here.
I don't know about the additional "unauthorised access" but I'd be surprised if someone can't make a case from cracking a password to do something on a network you know shouldn't be possible unless you were the person who owned the address.
Alternatively: imagine you were selected to sit as a juror in such a case. Would you nullify?