(To be clear, in this question I’m not asking about how to protect a login form against brute-force attacks.)
I work for a company which designs and builds microsites for competitions that appear on consumer products. If you’ve ever bought a packet of crisps which has prompted you to look for a unique code printed inside the pack and enter it on a website, then you can imagine the sort of site I mean.
The codes are usually supplied to us by our clients, and with few exceptions comprise 8 uppercase alphanumeric characters.
The website asks for a unique code, the user’s name and email address, and requires that they tick an “I agree to the terms & conditions” checkbox. A successful entrant will usually be told instantly if they have won a prize.
Typically we use reCAPTCHA (the tick box variant) to mitigate against bulk form submissions, but I worry that this is insufficient to prevent a determined attacker from flooding the site with thousands or even millions of codes they have generated.
What other steps I should be taking to ensure the security of these websites? Would a DDoS protection service (such as those offered by AWS and Google Cloud) be a good fit?
So I’ve tried bruteforcing my server using thc-hydra’s https-post-form, but it floods the server very quickly and the requests start timing out.
However, If I go through the browser where the HTTP header Connection: Keep Alive is used and accepted by the server, I can make a lot of requests in rapid succession without flooding the server.
Is there a tool like hydra that can be used to send many https post requests using a single tcp connection?
How difficult to crack a KeePass file which use KDBX4 file format if someone only obtain the file without knowing any hint of the master password?
With assumption the password length is equal/more than 20 character, uses lower cases, upper case, number & non-alphanumeric character on QWERTY keyboard.
P.S. i know there’s similar question at How difficult to crack keepass master password?, but it was created before KDBX4 released
I have been running a brute force attack on multiple zip files with multiple .csv in them. Though I can see the file name and size, when I try to open the .csv it prompts me with a password. After letting it run for a few days(it’s still ongoing), I found 2/1128 passwords so far. However, the two files I found a password for are 2 bytes in size, and have nothing inside of them.
Do you have any advice on what I can try to do next to recover these files? I’m currently using a software called PassWare to perform this. Is brute force the only option if I have no idea what the password could be?
Many security algorithms today have such a large key length, that there’s just no use in trying to brute-force a key. For example to find one AES-256 key you would have to try 2^128 keys on average.
My question is, if there’s a special name for a brute-force attack where you would somehow know that a key “lies” in a specific range, which would reduce the amount of calculations so drastically that a brute-force attack suddenly becomes feasible.
An example about simple brute-force RSA-factorization might make it more clear:
We have a 2048-bit RSA key. Way too large to just try one number at a time to brute-force it.
But we assume now that I have a special algorithm that doesn’t directly return one of the factors, but can tell us that one of the factors lies in a certain range k (plus / minus 1,000,000,000). Then we would only have to try the possibilities from k – 1,000,000,000 up to k + 1,000,000,000 and this is probably quite possible to brute-force.
No matter if such algorithms exist or not, is there a special name for this specific attack (reducing the possible key range to make a brute-force attack feasible)?
Twice a week I receive an email to email@example.com that says:
An attempt to brute-force account passwords over SSH/FTP by a machine in your domain or in your network has been detected. Attached are the host who attacks and time / date of activity. Please take the necessary action(s) to stop this activity immediately. If you have any questions please reply to this email. Host of attacker: <MYIP> => server.mydomain.tld => mydomain.tld Responsible email contacts: firstname.lastname@example.org, email@example.com Attacked hosts in our Network: 188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206 Logfile entries (time is MET / GMT+1): Sat Jun 22 06:51:55 2019: user: vnc service: ssh target: 220.127.116.11 source: <MYIP> Sat Jun 22 06:48:29 2019: user: mysqldump service: ssh target: 18.104.22.168 source: <MYIP> Sat Jun 22 06:46:59 2019: user: testftp service: ssh target: 22.214.171.124 source: <MYIP> Sat Jun 22 06:45:59 2019: user: www-data service: ssh target: 126.96.36.199 source: <MYIP> Sat Jun 22 06:44:29 2019: user: ubuntu service: ssh target: 188.8.131.52 source: <MYIP> Sat Jun 22 06:43:29 2019: user: postgres service: ssh target: 184.108.40.206 source: <MYIP> Sat Jun 22 06:41:59 2019: user: ubuntu service: ssh target: 220.127.116.11 source: <MYIP> Sat Jun 22 06:40:59 2019: user: dong service: ssh target: 18.104.22.168 source: <MYIP> Sat Jun 22 06:39:29 2019: user: root service: ssh target: 22.214.171.124 source: <MYIP> [ ... other 4 IPs ... ]
They are always the same 4 IPs. For SSH authentication I use Google 2 factor, I have root user disabled and only an user allowed. I have also changed che port. This is a VPS by OVH where I have a mail server so I’m a little worried.
Many recommendations for storing passwords recommend
hash(salt + password) rather than
hash(password + salt).
Doesn’t putting the salt first make it much faster for the attacker to bruteforce the password, because they can precompute the state of the hashing function with the bytes of the salt, and then each time of their billions and trillions attempts they only need to finish calculating the hash using the bytes of the password.
In other words, each bruteforce iteration needs to calculate only the hash of the password
intermediateHashState(password) instead of the whole
hash(salt + password).
And if the salt was placed after the password, the attacker wouldn’t have this shortcut.
Does this advantage exist and is it significant?
My question is simply how much time an attacker needs for full bruteforce on typical complexity password policy given either kerberos ticket/ as req or Ntlm transaction.
This depends on the algorithm used (rc4/aes). Assuming a typical propiotery hardware.
I have ended up wiping my ledger nanao S during test (thoroughly stupid I know) and I am left with 23 (!) seed words and a passphrase. I understand that I should have both backed up my wallet, and made sure of my seed words. I was looking into a program (in python due to there not being too many combinations) that could brute force it due to me knowing that I had written them down in order, just having missed a word, (pasted here due to the massive size due to the size of the word list)
So how would I go about brute forcing it through python, what I have now can (as far as I can see) will give me all of the valid mnemonics, but from there how would I automate the collection of private keys from a bip-39 generator, and the checking of funds in them?
(edit) I know the order of the words, just not where the missing one is, Ive tried to manually sift through the combinations for if the missing word was the last one
(further edit) Im using an offline version of this site for turning the mnemonics into private keys iancoleman.io/bip39 but unfortunately I dont know how to canabalise the code or interact with it with python. from there I was going to use a tool like this github.com/gurnec/btcrecover to find the wallet with btc in it. At least thats what I have so far.
I have managed to lose 5 words of my 24 word Ledger Nano S recovery phrase. I have words 1-19 but I am missing words 20-24. I have significant holdings on the wallet so would very much like to recover it if possible. The passphrase is a BIP39 mnemonic (see https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki). I have the bitcoin and ethereum public addresses for this mnemonic. I am wondering if it’s feasible to brute force the passphrase.
Each word is 11 bits (2^11 = 2048 possible words). The last (24th) word of the passphrase is of the following form [3 random bits][8 bit checksum]. Therefore I only have to check 2^(55 – 8) = 2^47 = 1.4×10^14 combinations. I would have to compute SHA-512-HMAC with an iteration count of 2048. As far as I understand, that means I’d have to compute 1.4*10^14 * 2048 = 2.87*10^17 hashes in total.
Is there any hardware out there designed for this? I am aware of ASICs that compute sha-256 hashes but not sha-512 hashes. Perhaps I could tweak one to work with sha-512 since they are very similar.
Assuming a fairly typical ASIC hashrate of 1TH/s (10^12 hashes per second), I could exhaust the search space in 2.87*10^5 = 287000 seconds = 3.3 days. I’d probably get there sooner, of course (expected 1.65 days). Time is not something I am worried about. Even if I have to wait months, I don’t mind – so if I can get 10GH/s at a reasonable price, that would be great.
I would really appreciate any help/information you could provide to help me out and make sure I haven’t missed anything. I could also use GPUs for this (I calculate I can run them at roughly $ 1/10TH – so it would cost me $ 28.7k to exhaust the search space, which I will do if there are no cheaper options).
Many thanks, James