Tag Info

Hot answers tagged


No. This is known as a known-plaintext attack (or a chosen-plaintext attack if you are not only aware of but can select the plaintexts), and is a type of attack that AES is highly resistant to: there are no known attacks of either type that are faster than brute force. If you've got access to the encryption coprocessor (and a good electronics lab), you may ...


Stay calm, and be nice to the person reporting this. If they are contacting you, they only want to help, so do not threaten them. Also don't ignore them, make sure they understand that you are interested in fixing this. Explain to them that you need time to do this; ideally you can give them a time frame in which you think that you can have this fixed ...


If you ever need to check a suspicious URL, you can use a service like urlquery to check if it has a malicious reputation, the HTTP transactions that take place, any java script that runs, etc etc. Very useful. They also provide a screenshot of what the visited page looks like. http://urlquery.net/


%E2%80%8E is percent-encoded UTF-8 for the Unicode character "U+200E". It's used to make the text after it display in left-to-right reading order, such as when displaying an English-language quote in an Arabic text. Unless you've got some seriously broken software, it has no use as an attack. My suspicion is that this was a prank that didn't work out: if ...


I would say a malicious internal actor. Internal actor meaning that he is validly participating in the network, but malicious indicating he's abusing the system.


Users of applications cannot. They can only try to not have rogue apps running on their systems. In this case we have an app that is normally harmless or even (attempts to be) beneficial unless it detects you're approaching a juicy login. Some, each alone insufficient, ways of "protecting": do not install untrusted apps or from untrusted sources. pay ...


I agree that this isn't the best wording. Essentially, it means that there are unusual circumstances in order to exploit this. In the specific case of this bug, you have to get the user to connect to a malicious server under your control, or Man-in-the-Middle a connection to a legitimate server. The vulnerability is a simple stack overflow on the version ...


In the Information Security world, internal attacks or inside malicious attacks are known as Insiders. Someone who can poke, sniff and even can do anything with a trusted identity is an Insider and can install malwares and anything bad.


For me, insider attacks and internal attacks perfectly fit your description. If you want to find a more specific name maybe try to be more specific on what kind of malicious activities the node is carrying out in the network. The paper [1] is from the field of wireless sensor network (WSN) security. A WSN is a distributed system of sensor nodes. There are ...


Normally we call that kind of attack "spoofing". It usually implies that there's some kind of active interaction involved, whereas sniffing is passive.


The last resort attack in this case is the way some of the early BluRay keys were obtained, that is burning away the outer layers of the chip with HF and reading off the crypto key from the chip itself.


The most powerful feature of oclHashcat is the rule based attack. The rule engine can accept characters to rotate the passwords in the list, so using the '{' character in the rule file will rotate the word left by one char. 'abc' will become 'bca', then 'cab'. You can also reverse the word using 'r', 'abc' will become 'cba', then rotate left or right if you ...


There is no proof that the message was intended for B. So, intruder I can intercept the message signed by A and redirect it to B, authenticating I as A. But what is a harmful attack? For example in a bank-client interaction scenario? If I understand you correctly, you've just described the first part of a Man In The Middle (MITM) attack.


Being disconnected results in an annoyance for legitimate users if we make a mistake coding the "misbehavior detection" With proper code review, mistakes like these can be avoided. Killing the client eliminates the need for "clean up" response code. Although it is important to "kill" a malicious client in order to prevent further issues, personally, ...

Only top voted, non community-wiki answers of a minimum length are eligible