New answers tagged

0

There is one possibility for this: Google it - literally. If the file has been uploaded to any of a number of file-sharing sites already, they have likely posted a hash of it, and it may have been indexed. For example, google '60CCE9E9C6557335B4F7B18D02CFE2B438A8B3E2'.


0

Preface: a hash is normally utilised in verifying the integrity of a file or set of data. Provided the checksum hash is inclusive of the data and name, then that could be a reference point for the container, which then could be implemented in searching through checksum pattern matching. Provided you knew a salt (which could include the date or time value ...


1

You mean, that people use passwords like "abc123" and hash them to SHA-256 to get "6ca13d52ca70c883e0f0bb101e425a89e8624de51db2d2392593af6a84118090". And then they think that the second is more secure than "abc123". But is it? Yes, the hashed version is in some cases more secure when we're talking about password-entropy. Because it's longer, has more ...


0

Your firewall is just working. Nothing to complain about. It's allowing only that IP, the others are getting blocked and logged so that you know someone else is trying to reach your RDP.


0

AES is considered today to be the best symetric crypto algorithm to use. AES-256 is perfect, and with 40 characters, this is more than enough.


0

You shouldn't be using openssl to encrypt files. You should use gpg -c instead (which encrypts it with a symmetric cipher). Using openssl causes it to lack authentication, key strenthening, etc. To answer the question though, a 40 character password (assuming it's entirely random chosen from a 95 character keyboard, since you gave no information about the ...


0

The only time it could be relevant is for cracking a password that is very secure. Mike Scott's math is accurate, so lets presume that 22 character password is going to take 100 years to crack. If we don't know it's length then we'll waste 9 months attempting passwords that are too short. Then at a random point in the remaining 92 years the password will be ...


0

According to this article on Wired, it is. https://www.wired.com/2016/06/hey-stop-using-texts-two-factor-authentication/ The attack: "... The hackers, as he tells it, had called up Verizon, impersonated him, and convinced the company to redirect his text messages to a different SIM card, intercepting his one-time login codes."


0

Regarding how long it would take, if we use a tool like crunch to generate the wordlist to use for cracking said PDF file, the output would be this: [root@yokai ~]# crunch 20 20 ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 Crunch will now generate the following amount of data: 11388113619364347904 bytes 10860551471104 MB 10606007296 GB 10357429 TB 10114 PB Crunch ...


0

The only attack that doesn't take millions of years requires a lot of money. Custom build a 32 nm AES cracker Build 50 chip plants to make these chips Spend a year making chips Build a giant cluster of systems Run the cluster for 1 year Note that the R&D cost on the chip will be anywhere from $50-$250 million, the plants will be $1-2 Billion each and ...


1

Something like this was actually done in some versions of the RAR compression software (in the early days, not sure if it still is like this). An encrypted archive would be decrypted by any password entered, but a wrong password would result in gibberish output. It was done to prevent brute-forcing of passwords which at the time was feasable for ZIP archives ...


4

Sounds like you're talking about a form of "deniable encryption" or "plausible deniability" in the context of crypto; that is, an alternative secret that decrypts to plausible but non-authentic plaintex. See https://en.wikipedia.org/wiki/Deniable_encryption for details. But strictly speaking, if someone has the capability to bruteforce your ciphertext, they ...


6

The effect is tiny Let's suppose that your system transforms practical brute force from decrypting the first four bytes (realistically, the first much larger block, but whatever) to having to decrypt the full e.g. four gigabytes of encrypted data, making bruteforce attempts approximately billion times or 2^30 times slower. Now, that might seem a big ...


1

For remote access, as others have said, simple lockouts and delays can work. For passwords, what you have is a one-way hash. To validate the password, you re-hash it, and compare the two hashes. Having more than one simple password produce a valid match against a single hash is considered undesirable: it means the hash is weak, and has "collisions". So it'...


5

Most already has been said, I just want to offer another perspective. Imagine you would try to secure a house with this technique. You would let the intruder give access to a cellar room if he tries to open the door for some time. The question is, would you want an intruder even there? The intruder will most certainly realize that he didn't get what he ...


2

The problem with keys is they exist as data and not as running code. Even with the CA and Crichton example, what happens is an out of band procedure occurs that provides you with reasonable responses for each decryption try. Mathematically this is impossible on the level of a ciphertext and brute force attempts.


42

Fooling an attacker with false positives isn't a bad idea, and it's not new. The following may interest you. Cryptographic Camouflage CA technologies has patented a technology known as Cryptographic Camouflage. A sensitive point in public key cryptography is how to protect the private key. We outline a method of protecting private keys using ...


13

To give you a straight answer, yes, it is possible to reduce the effectiveness of brute-force attacks and it can be done the way you suggested, but shouldn't. You can get very similar results just by implementing timing delays between each failed attempt and the next guess. Also, (just for your knowledge) very sophisticated and similar technologies have ...


105

The answer always depends on your threat model. Security is always woven into a balance between security and usability. Your approach inconveniences the hackers trying to break into the account, but also inconveniences a user who merely mistypes their password. If the fake account is believable enough to fool an attacker, it may also be believable enough ...


0

I would recommend disassembling the drive's firmware and taking a closer look at the crypto inside. With this kind of proprietary crypto it's often flawed and you may find bugs that will make your attack much easier, as pure bruteforce on correctly implemented AES is infeasible.


3

Sufficiently long passwords generated by a secure random number generator hashed by an algorithm with long output (at least 128 bit) and no known weakness (at least SHA256) will become infeasible to bruteforce (either against a single hash or compute a useful rainbow table) and salting will not be necessary. Your description of your implementation doesn't ...


3

Such strong passwords can be safely stored unsalted with a fast algorithm like SHA256, there is no problem in that. The problems are different, you have to trust the client, the secure transportation to the server, and you have to make sure that the generated passwords are indeed unpredictable.


1

Yes, you can brute-force a hardware-encrypted SSD drive. The time it takes to be successful though is up to the method used, the length of the password and the hardware & software capabilities of the machine doing the BF attack (which dictates how many tries/sec can be attempted).


3

Yes, Windows 10 use PINs as well as passwords, there are options to make PIN usage more secure. Fore example, if you enter wrong PINs several times, it will lock, so after that, you will have to enter unlock PIN, you will see under the login form, this is not so good security option for Windows 10, but it works.


7

Is it possible to perform MITM on HTTP POST? HTTP is not encrypted, so if you "get in the middle" you can read the communication and modify it. You can get in the middle by e.g. hacking a router or cutting a cable. Your ISP is already in the middle and can read your HTTP communication. This is true for all HTTP methods - POST, GET, etc. Is it possible to ...



Top 50 recent answers are included