Why does my SHA256 certificate get encrypted with 168 bit 3DES?

Your question appears to have nothing to do with certificates or hashes. Neither one involve symmetric ciphers (like DES or AES) at all. The actual answer is just a matter of how Outlook (or Mail.app) is configured on each machine, nothing more. I don't know how to control the ciphers used on Outlook for Mac, but here are the steps for Outlook 2013 on Windows; hopefully you can find their equivalent on Macs:

In Outlook, open the File tab on the left of the ribbon.
Select Options from the left sidebar that appears.
In the "Outlook Options" window that pops up, select Trust Center from the left sidebar.
Under the "Microsoft Outlook Trust Center" heading, click the Trust Center Settings button.
In the "Trust Center" window that appears, select E-mail Security from the left sidebar.
Under the "Encrypted E-mail" heading, click the [Settings] button.
In the "Change Security Settings" window that appears, under the "Certificates and Algorithms" heading, check the "Encryption Algorithm" drop-down. Set it to AES (256-bit) if it isn't already set to that.

You might find the following page helpful for your Outlook for Mac users: https://support.office.com/en-us/article/Digital-signing-and-encryption-settings-8A6EB21D-0BEB-4E66-A63A-2D362966CF77. In particular, it tells you the steps to get to the settings page:

  To access these settings from the primary Outlook Accounts preferences screen, select the account, click Advanced, and then click the Security tab.

After that, it should be similar to the instructions above (under "Encryption settings", find the "Encryption algorithm" option and select AES-256).

Something to clear up: the certificate has nothing to do with the symmetric cipher used for bulk encryption. There are three types of cryptographic primitive in use, here, and none of them have anything to do with the others:

Asymmetric ciphers (in this case, 2048-bit RSA). These have pairs of keys, a public key that you let everybody see, and a corresponding private key that you don't let anybody see. Anybody with the public key can encrypt a message such that only you (the holder of the private key) can decrypt it, and anybody with the public key can verify that you signed a message using your private key. However, these ciphers are extremely computationally expensive, so usually you only encrypt or sign a short string (a symmetric key for a message or a hash digest of a message/certificate, respectively). Encryption provides privacy / confidentiality (nobody but the holder of the private key can read the message). Signing provides authentication (only the holder of the private key could have created that signature) and integrity (if the message is tampered with, the signature won't verify correctly, so if it verifies you know the message wasn't messed with). These are used for:

a CA (Certificate Authority) signing a certificate's hash (so that the recipient knows the certificate is yours and nobody is spoofing your key)
a message sender signing a message's hash (so the recipient knows you sent the message and it hasn't been tampered with)
encrypting a bulk encryption key to send with a message (this key is usually randomly generated for each message, and is never exchanged in plain text).

Symmetric ciphers (like 168-bit 3DES or 256-bit AES). These are used for the actual message bodies (and attachments) that are being encrypted. They are fast, but the same key is used for both encryption and decryption (that is, they are symmetric) so there is no public key that you can safely share with the whole world. Thus, the symmetric key for a given message is sent protected by asymmetric encryption. These provide confidentiality only.

Many symmetric ciphers are a type known as block ciphers (this includes all forms of AES, DES, Blowfish, and many others). Block ciphers work on fixed-length blocks. To be used with messages longer than one block, one uses a mode of operation; some of these are more secure than others. To securely encrypt messages that aren't an exact multiple of the block size, one uses padding.
While padding can make it possible to detect naïve tampering with the encrypted data (or ciphertext), it is easy for a skilled attacker to bypass this detection. Also, padding is not always used since the data to encrypt is sometimes reliably an exact multiple of the block size (for example, hard disk sectors). Therefore, padding alone should not be trusted to provide integrity.
Similarly, the most common modes of operation (CBC or CTR) do not provide integrity. Tampering with data encrypted using a block cipher in CBC mode can produce attacker-controlled changes in the decrypted data, although it will corrupt data beyond that. However, some modes of operation (like GCM) also ensure integrity when decrypting. If only one other party has the symmetric key, then these modes also provide authentication (you know that the message came from the other holder of the key). An algorithm that provides confidentiality, integrity, and authentication is called authenticated encryption.
There also exist symmetric stream ciphers (such as RC4, which was widely used until exploitable weaknesses in it were discovered). These have no block size, need no padding, and are usually extremely fast. However, they only provide confidentiality, and must be combined with other primitives to provide integrity and authentication.

Hash functions, sometimes called one-way encryption, like SHA-256 (a member of the SHA2 family). Hash algorithms are used to produce short codes called digests (suitable for asymmetric signatures) that can be used to demonstrate that something (like a certificate or message) has not been tampered with. The following are some properties common to secure hash algorithms:

Resistance to preimage attacks. That is, having the hash digest doesn't make it possible to produce the original data that was hashed to produce this digest.
Collision resistance. For a given message (such as an email or certificate) and its digest (such as was used to create a trusted signature), it should not be feasible to find a second message that produces the same digest.

The choices for one primitive have nothing to do with another. You can have somebody's certificate that was signed using 512-bit RSA (super weak) signature of an MD5 hash (cryptographically broken) but contains a 4096-bit RSA key that you can use to encrypt messages back to that person. You can't trust the signature on the certificate, but if you trust the source of the certificate anyway there's no reason you couldn't use that super-strong RSA key. You can encrypt a message to that person using the incredibly weak DES (56-bit) cipher, or using 256-bit AES; for either one, you'll send the symmetric encryption key protected by that 4096-bit RSA key.

There exist an enormous number of potential combinations of primitives (asymmetric and symmetric ciphers, hash function, key exchange algorithm if needed, mode of operation if needed, padding algorithm if needed). A number of popular ones are grouped as named "cipher suites" for use in TLS. That term is not commonly used for S/MIME (and some available features of TLS, such as ephemeral keys, are not available for asynchronous communication like email). However, the idea of combining a set of primitives to provide strong security against multiple types of attack is still relevant.


Can I rely on anti-virus scanning "data" objects in installer?

Here's something important: in an information security field, a "trusted source" is not only a source which, as you believe, won't cause you any harm intentionally. It's also a source which won't cause you harm occasionally due to ignorance or carelessness.

"A source which can provide an installer with untrusted contents" sounds like a definition of an untrusted source. Even if it's, say, your father or sister, you still need to assess the information security threats based on how much do they know about information security, not only on how much do you trust your close relatives in general.

If your close relative has just downloaded an installer somewhere and then sent it to you, it still doesn't come from a trusted source in any sense. So it's still better to avoid running it.


How can I find a SHA-256 hash with a given suffix using hashcat?

This is not possible using hashcat, unless you're ready to change the source code to suit your needs.

For example, you can adapt s3inlc's fork which added an option to check for hashes with some specific properties (starting / ending with as much 0 as possible, etc.).


What would be the best way to authenticate a user in an offline, multi-user mobile environment?

Well, you can just invalidate the token and delete it whenever you want to switch users or otherwise "log out" the user, than use the online authentication with the online password check.

The only way to reliably protect a token from offline attack (as far as I can tell) is to encrypt it, which would require a password or pin. You should use a slow password derivation function with enough iterations, such as PBKDF2 to help with the entropy a bit.


HOTP with as HMAC hashing algoritme a hash from the SHA-2 family

HMAC/SHA-1 is not broken. SHA-1 has a weakness with regards to collisions (and it is still "theoretical" since producing a collision for SHA-1, though conceptually easier than the generic attack, is still so expensive that nobody has computed one such collision yet). But HMAC resistance does not rely on resistance to collisions.

Indeed, HMAC is proven secure as long as the hash function which it uses is a Merkle-Damgård function which itself relies on an internal "compression function" which behaves like a PRF. This is rather technical. To make a long story short, the known weakness of SHA-1 voids the proof, but nobody knows how to turn that into a weakness on HMAC/SHA-1. Empirically, we have the example of MD4: MD4 is extremely broken with regards to collisions, with a near-zero cost (computing a collision for MD4 takes less time than actually hashing the two colliding messages to verify that it is, indeed, a collision), and HMAC/MD4 is also broken, but with a quite non-trivial cost of 258 plaintext/MAC pairs (and that's a forgery attack, not even a key recovery attack), making it utterly non-applicable in practice. If we have the same kind of ratio for SHA-1, then HMAC/SHA-1 is still very safe.

Nevertheless, HOTP can be used with any hash function but this requires "adaptations". On a general basis, thou shallt not fiddle with cryptographic algorithms. That being said, it is rather obvious (at least for a cryptographer) that replacing SHA-1 with "SHA-256 truncated to 160 bits" in HOTP will yield something which is equally secure (i.e. the detailed security analysis of HOTP fully applies with that alternate hash function). However, changing the hash function means that you can no longer test your implementation with regards to the published test values, and that's a big worry. Implementation bugs are a much more common source of practical vulnerabilities than cryptographic weaknesses.

Therefore, use HOTP with HMAC/SHA-1 and be happy. It is not broken.


With what permissions does the Android lock screen operate?

Android has an API for music players. Those buttons you see? They're universal, and when they are pressed, they tell the app currently playing music to change/stop/pause/play the track, but Android displays them on the lock screen, not the apps themselves.

Your analogy is incorrect. Sticky keys is an application, these buttons are not separate from the operating system. Also, Windows and Android are two very different things.

Also, widgets exist for android lockscreens on many devices, and these do not require root...


Outlook was redirected to the server clblgn.sceur.ch to get new settings

The serving IP for that URL is 83.97.124.41.  That is an IP owned by HoistGroup SA.  They provide networking and communication services for the global hospitality industry.  I definitely wouldn't trust that link.

For this particular issue with outlook check out Microsoft's page to probe connectivity issues. testconnectivity.microsoft.com


A public key matches a specific private key, it is not "kind of like a person's name". The public key can be used to verify that whomever signed the message has the private key belonging to the public key, because the private key and public key are related in a very specific mathematical way. In theory, there is only ever one person who has that private key, allowing the server to identify you.

However, if the private key is stolen somehow, now anybody could be signing that message. Hence the need to generate a new private key. But since the private key and public key are paired in a specific mathematical way, the new private key is useless without sending the server the corresponding public key that was generated along with it.


How Hole 196 actually works ? What WPA parameters does it exploit?

The hole 196 flaw consists basically in take advantage of what page 196 of the standard says... it says that messages sent with group keys, ie keys intended for broadcast communications, do not have protection against spoofing. Thus, an attacker can send a message with a GTK key with the IP that he wants.

The point of the attack is to send a message with a GTK key but directed to a target MAC instead of a broadcasting MAC address. By doing this, only the victim will process that broadcast packet and, therefore, unless the ARP table has static resolution for the MAC of the gateway, IP poisoning will occur which will allow the router to be supplanted.

Since that moment on, when the victim communicates with the Gateway, the PTK keys associated with that IP will be used, which the attacker will kindly deliver to make the MITM. Simple but functional.

It doesn't care if is a Robust Secure Network using WPA2 and AES. It can be performed anyway but with client isolation you can avoid the problem. Anyway, performance will be compromised.


The VM approach helps in that "what happens in the VM stays in the VM".

You would do your things in the VM and then reinstantiate it every time (there was, perhaps there still is, a Windows helper app called SteadyState that allowed a sort-of-VM to continuously be recreated while still being kept updated).

The essential thing is that the VM have no access except to the Web. Your personal documents, etc., would stay outside the VM. If you need to download a file, you would download it in a "shared folder" and then run a virus scan from the guest operating system once the VM is down.

This way, in theory, no virus or malware can infect the guest operating system unbeknownst to the user.

Your sequence of operation would be:

keep the "pristine" virtual machine somewhere (say C:/VM/Pristine).
copy the VM into C:/VM/Dirty
fire up Dirty and use it to your heart's content
copy any files you need from Dirty to C:/VM/SuspiciousFiles
power down Dirty
delete it. Any virus, malware, etc. is thereby destroyed.
virus-scan the contents of SuspiciousFiles

Occasionally, you would fire up Pristine, run Windows Update or zypper update or apt-get update or whatever, then power it down again, ready to be cloned into a new Dirty.

As for anonymity, your IP address would be still visible, but you could configure your VM to be a "stock" machine with all default options, in no way different from millions of others. Even frameworks such as Panopticlick would be hard pressed to reliably recognize it.

UPDATE: reverse protection

A similar level of isolation, but lower, exists between the outer machine and the VM (i.e. you want to use a clean VM on a possibly dirty machine). What happens is that a virus or malware in the outer machine has full access to the files constituting the virtual machine, but normally and as far as I know, it would be too complex for a malware to try to influence the virtual machine through the virtualization layer. Even so, protection against the hosting machine is less reliable, and the VM's very existence may be jeopardized (for example by some ransomware such as Cryptolocker, deciding to encrypt all large files in the hypothesis that they must be valuable).

In such cases it is best to employ a different approach, that of a portable machine on a bootable USB device. There are many such; this is one. The idea is that when you need to perform some sensitive operation, you reboot the machine and boot it from the USB device. The machine will restart (should restart, if the USB application is well built) with no connection to the outside except basic networking, and no knowledge it even has a hard disk. Everything you do will only exist on the USB which will then be put back in your pocket when you finish. There's still a remote risk of so-called bluepilling rootkits having rogue access to the USB while it's plugged in, but as far as I know it's (for now at least) more theoretical than realistic.


Why do some sites enforce low-security passwords?

There are a couple reasons:

Legacy software
You may not know, but the vast majority of financial data today are processed on IBM mainframes, running applications written in Cobol and not updated since the last century. IBM already have provided way better security to the mainframes, but as there are still businesses running Windows XP in the desktops, not everyone is using the new functions.

Passwords in the clear
Yes, they exist. Some places store password in the clear, and the password field is something like PASSWORD TEXT(16). This limits the allowed size of the password.

Sanitization of the password
Some developers sanitize the input, and that's good. But not so when the input is a password. If I want my password to be <script>alert('XSS!')</script>, what's the problem? If everything goes right, that value is going to be salted and hashed. But some people think special chars on a password will break their code, so they break your password instead.

Server-side encryption
The above is true here too. Some places encrypt the password with reversible encryption, and no matter how strong is the encryption, it's a terrible idea. Passwords are to be salted and hashed, anything else is wrong. But to prevent special chars breaking something, they disallow them. The 16-char limit is also because of this. If they are using a 128-bit key, the password must fit a 16-byte "packet" to be encrypted.

We need a public shaming site that lists sites that do this

Something like The Plaintext Offenders...


License key / Serial number generator and checker

If there is no real need for security, then here is a very fast serial number generator, with a checker:

User a counter. Initialize it at 0. When you want a new serial number, increment your counter by 1000; the new counter value is the serial number. The checker works like this: a serial number is valid if it ends with three zeros. Only one of every 1000 numbers will be accepted by the checker.

If this solution does not please you, then you do have a need for security, and this calls for cryptography.

The cryptographically secure solution is to have signed serial numbers: the serial number is the encoding of some payload (e.g. a counter of all serial numbers that you have generated) and a signature over the payload. The generator has a private key, which it uses to compute the signatures; the checker only knows the corresponding public key. The trouble with this setup is not really about verification time, even in Javascript; rather, it is the size of the signature which is a problem. I assume that the serial number will be, at some point, typed by a user. The minimal theoretical size for a cryptographically secure signature is about 80 bits (since signatures can be verified with only the public key, an attacker could try all possible bit sequences, and we usually require a security level of at least 280). However, the smallest signatures among the "assumed to be secure schemes" are closer to 160 bits (with BLS, which uses a pairing, which is kind of complex to implement) or 320 bits (with DSA or ECDSA). There is some work on signature systems with shorter signatures (Quartz, or McEliece-Niederreiter) but there is quite some controversy on their security.

Even with both uppercase letters and digits (36 possible characters, and there you have both 'I' and '1', and also 'O' and '0'), a 160-bit signature will use 31 characters. Along with the payload, you will end up with serial numbers of length 35 or so, which is probably too much for an average user to type in (but not by a large margin; an 80-bit signature would fit nicely).

If you do not use a signature scheme, then you must be aware that a reasonably determined attacker will be able, through some disassembly, to circumvent the checker, or even to learn enough to be able to produce his own serial numbers (which the checker will happily accept). At that point, you will not get quantified security: you will not be able to say: "my scheme is secure up to a budget of 3.8 billion dollars". Rather, it will go as: "my scheme is secure until a sufficiently witty and bored student comes along, reverse-engineers the checker code, and publishes the result on Facebook".

The classical not-really-secure scheme would look like this:

Use the counter from the previous scheme (the one with ends with three zeros). Encode it as a 64-bit block. Encrypt that block with some hardcoded symmetric key, using a block cipher. The checker knows the key, and verifies the serial number by decrypting it (with the same hardcoded symmetric key) and looking at the final zeros.

This is not really more secure than the plain counter, but at least the serial numbers will be random-looking. With an alphabet of 34 characters (digits and uppercase letters except 'O' and 'I'), a 64-bit block requires 13 letters, which is probably acceptable (a typical Microsoft serial number has 25 letters). For the 64-bit block cipher, I recommend XTEA, which should be fast and simple enough to implement.


Erasing the contents of a photocopier hard drive, in such a way that the copier can use it again

There's no other way. Open up the copier, take the hard drive out, use the linux shred command and the copier will be able to use it again.


How much information is released when paying with a debit card

I'm working from the assumption that this is a check card (it may go by various names in different places) that are part of the Visa or other payment processor network and not specifically an ATM card.  There is a difference and I rarely see the ATM cards now.

The check card, like credit cards has in its track 1 your name along with some other information about the account (expiration date, account number and such).

With just this information, there is not enough information to pin you down to an individual and your address.  However, more than companies ask for your zip code when paying by credit card (note, this is not the case when paying using a pin as it already provides the two factor identification and goes through the payment system a different way).

Asking for a zip code plays two roles - first, it can reduce their rates with the payment processing company as it adds another little bit of information about you to help ensure this isn't a fraudulent purchase (you often see this at a gas station where there is no human check on the use of the card).  Secondly, zip + name is often enough information to identify an individual with address lookups.

Going back to the tracks... a debit only card has only track 2.  This contains only the information about the account - the person's name isn't there.

When using a card with track 1 and track 2 (the visa check card), the company does have the name of the person.  However, this alone isn't enough to identify a person and the bank and payment processor under normal situations will not release the billing address of the account (gathering marketing information would not be sufficient to need the information).

Expanding on this, being able to tie a customer to an individual is a very important thing for retail companies - especially for trying to track them across multiple visits and possibly multiple stores too.  Companies are often very interested in this data and willing to spend a fair bit to acquire it (coupons, discounts and the like).  Famously, the target data mining story of 2012 shows how much data can be leaked about an individual's personal situation. (chase the links on that story - there are a couple other good reads related to it, particularly the NYT article how companies learn your secrets)

There are two forms this takes - rewards cards, and company branded credit cards.

The rewards cards are rather simple.  You use it at a check out and you get points or something.  If this has your phone number, email address, or physical address tied to it (some do) it is a rather trivial matter to attach a given purchase to a given person.

With company sponsored credit cards (the type that one typically finds with larger companies - the Macy's card, Sear's card and the like) it is possible for the company to go back either to the application that passed through them to get the card or going to the credit card company directly to get the billing information if necessary.

This also extends to company sponsored rebates, in store credit...

Thus, if you use anything else that is identifying to you as part of a purchase, it is quite possible to trace the information back to an individual (even if one pays with cash otherwise).


Passport copy is being used to defraud others - what can I do?

1) There is truly nothing you can DO to STOP them from using your identify in the current manner. The best you can do to impede them is to essentially "cyberstalk" them and report their every attempt to defraud someone to the system administrator or security team of the website they use to do this. So essentially hit the 'Report Abuse' link.

It gets hairy here. It's now a he-said she-said situation. To put some weight behind your claims, and as recommended as one of the steps to take if you are a victim of identity theft, you should to file a police report to substantiate your claims. You can do that in their state & country and/or in your state & country. The laws within the U.S. do not completely cover situations of this nature, so I would not expect the laws in that country to be so much more ahead. Moreover, realize this is now an 'international incident'. So the agencies pathways to handle this are probably not established.  (When my ex had their credit card # stolen and recreated, while they still had the physical card within hand, the police agencies of both states were not equipped to handle this situation. Filing a report was like inserting ourselves into a pinball machine.) And a situation of this nature, crossing country lines, is probably not high on InterPol's to do list.

2) Yes and no. While there is a lot of information on the 1st page of your passport. The thief now has a clear picture (you mentioned photos in addition to the passport copy), your full name, D.O.B, state of your birth, your passport number and possibly a clear signature (if you copied the 1st two pages). While this alone is not enough for ID theft, it's working framework for the scam artist to build a case up around. They now have your email address and depending on their sophistication they can start to try to search for the other pieces of your ID puzzle (16 big pieces listed below).

While it seems like their motivations are not as lofty now, you could be an addition to their database for further mining. It might be best to take some precautionary steps. A good website for ID theft information and actions to take if you are a victim is: https://www.privacyrights.org/identity-theft-what-do-if-it-happens-you

Be sure to save your documentation of the incident (email exchanges, reports you filed, requests you made to credit bureaus, etc). Just continue to monitor your credit like you should normally be doing www.annualcreditreport.com (the only site authorized by federal law).

If any of your accounts (esp. the email account you used in the exchange) have a password that uses information on that passport page, or any other information you make have sent to this person, change it immediately.

As it relates to the harm of others, there is nothing you can do other than put out a public-service-announcement-of-sorts on the websites that the scam artist is listing on.

Good luck to you. Just keep your eyes open going forward.


Alright I figured it out and said I would post an answer.

The reason that the passwords showed up like they did is because they are encrypted with a pbkdf2 key that is stored in a specific keychain location (usually having the name 'Chrome' in it). To find this key you can execute the command security find-generic-password -wa 'Chrome' as an administrator and it should pull the key for you.

Once you have the key, in order to decrypt the you would need to;

Generate the IV (python -c 'import sys;sys.stdout.write("20" * 16)'
Get the salt (110% chance it's saltysalt)
Encrypt the found key using pbkdf2_hmac grabbing the first 16 characters and hexlify the encrypted key (python -c 'import binascii;import hashlib;key=hashlib.pbkdf2_hmac("sha1","<KEY>",b"saltysalt",1003)[:16];print binascii.hexlify(key))
Base64 encode the encrypted password and remove the first three characters (python -c 'import base64;print base64.b64encode("ENCRYPTED_PASSWORD")[3:]')
Decrypt the encryption with the following command: openssl enc -base64 -d -aes-128-cbc -v <IV> '<HEX KEY>' -K '<BASE64 ENCODED PASSWORD>'.

Luckily for you, I created a simple python function to return the same thing:

import base64
import binascii
import subprocess
from hashlib import pbkdf2_hmac

def decrypt(encrypted, key):
    iv = ''.join(('20', ) * 16)
    key = pbkdf2_hmac('sha1', key, b'saltysalt', 1003)[:16]

    hex_key = binascii.hexlify(key)
    hex_enc_password = base64.b64encode(encrypted[3:])
    try:
        decrypted = subprocess.check_output(
            "openssl enc -base64 -d "
            "-aes-128-cbc -iv '{}' -K {} <<< "
            "{} 2>/dev/null".format(iv, hex_key, hex_enc_password),
            shell=True)
    except subprocess.CalledProcessError:
        decrypted = "n/a"

    return decrypted

Please note, in order for the to work successfully, you have to have the administrative credentials for the computer you're running this on.


Asymmetric / end to end encryption for web messaging app

I think there is an additional problem/challenge with your scheme:
Beside the problem of having the key pairs generated by the server, this scheme also allows for a man in the middle attack:
A asks for the key of B, server answers with his own key C. Now the server can decrypt, read and encrypt again for B and send the new ciphertext to B. Neither A nor B will ever notice as long as the communication is done using the server.
To prevent this, you need to decouple key management server and message server. In the best case, you would use an active community key server like the ones for pgp for example.

Anyway, assuming the key management is done honestly, your hybrid encryption should work out.

Concerning the key generation, have a look at CryptoJS.
If I remember correctly, it is (almost) a full-fledged crypto framework that can also generate keys. You could use html5's local storage API to store the key client-side.


Is there such a thing as application-specific encryption?

There are several ways to do this but basically you are describing something of a digital rights management problem.

There are some open-source DRM programs like OpenIPMP which may help but there are probably other ways to solve your problem without using DRM.
https://sourceforge.net/projects/openipmp/

You didn't provide a lot of information about your needs or limitations but if it's an option the application could simply send the data to a remote site for decryption such that the application itself would never have access to a copy of the decryption key at any time. This could even be implemented as something of a streaming service of sorts.

Similarly you could implement a type of certificate-based PKI USB authentication token (hardware key). Again this type of solution is aimed at protecting the decryption key from other applications.

There are probably hundreds of ways to solve this problem but you may have to look at your limitations and options from a different perspective.

As much as I'm not a fan of DRM software solutions recently I've been seeing an increased need for easy to implement / free / open-source DRM solutions. It's an interesting problem to have.


How exactly do viruses get on computer when watching online porn?

Most common vectors:

Drive by download - Download is forced on to your computer, and you may either be forced or tempted to execute a malicious file. You are just browsing and all of a sudden you get freebooks.pdf.dll, or worse a browser/OS flaw lets the download happen without you seeing it.
Malicious advertisement with malicious javascript - Malicious javascript takes advantage of a browser flaw to exploit your system.

This isn't limited to porn. There are lots of other sorts of sites that have these problems.


I finally figured out what the problem was with the help of perror1. Since the execution appeared to be following the correct path when I specified the input through a file, I guessed that maybe the shell was running, but was being closed automatically. The referenced answer had a section called "Keep the stdin open after injection", which pointed me in the right direction and confirmed that the shell was indeed running.

I was able to get the shell by specifying the input like this: (cat input.txt; cat) | ./program


unauthorized devices appear in windows 10 network drive SMB

The first thing, in any network, is to check the access logs. What connected to those shares? From there, you gather as much information as you can on the devices/users connecting. That's how you investigate.

Monitoring wifi for unauthorised devices is usually done on the WiFi AP. But it is usually better to have the strongest encryption and a strong passphrase to join the network.


Is 3DES outdated for message authentication code computing?

3DES is a fine block cipher. The best known attack has academic cost 2112, which is way beyond the technologically feasible. The main issue with 3DES is that it works on too small blocks (8 bytes, instead of 16 like AES), but that is not necessarily a problem in a specific situation.

3DES is still an encryption system, so if it is used as MAC then this must be part of some sort of construction that provides a MAC out of a block cipher, e.g. CBC-MAC. 3DES is fine for CBC-MAC, as long as no stupid thing was done in the implementation (in particular, it is of paramount importance that the key used for 3DES in CBC-MAC is not used also for encrypting data). Short blocks imply that you would prefer not to try to process more than about 32 gigabytes of data with a given key -- probably not an issue in your case.

If 3DES is used in some other custom, homemade construction, then anything goes. Homemade schemes tend to be awfully weak, in some horribly creative ways. But note that the weakness would be the construction, not 3DES itself.


How safe is the encryption offered by Mac OS X's Finder?

I would not use TrueCrypt since it is no longer actively maintained, therefore, no longer safe to use. Truecrypts own website states “WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues”

I would recommend using Apple's Built In Feature it is safe and secure, and of course, your files are as secured as the password you use to secure them. As far as the algorithms used to encrypt your password, gives you two options, choose the more secure option is somewhat slower encrypting/decrypting, of course you will only notice the difference with large files. You can choose 128-bit or 256-bit AES algorithms. The cipher AES 128-bit and/or 256-bit are both very secure TSL/SSL use it to encrypt end-to-end traffic across the Internet, it is considered among the top ciphers (Although NSA has categorized this to be in Grade-B, and their recommendation is to use 256-bit keys for encryption). Anyway to answer your question most third party programs today offer AES among other options to encrypt your data, therefore, I don't see any reason why you shouldn't use the built in feature for encryption.


How to whitelist IP address mod_security CentOS 6

Found the way.

vim /etc/httpd/modsecurity.d/activated_rules/modsecurity_crs_10_whitelist.conf

And add this line:

SecRule REMOTE_ADDR "^192\.168\.50\.1$" phase:1,log,allow,ctl:ruleEngine=Off,id:999945


What are the security implications of STARTING a reverse proxied origin server as an unprivileged user?

The primary reason to start a service as root (which then downgrades to an unprivileged user) is to increase the separation between the service itself and what the service does.

The classic example is opening a privileged port, but there are other similar operations as well. For example, you may want the service to load configuration files which can't be accessed by the "child" service once the service is in operation.

Also, only root can chroot() to a jailed directory or setuid() to another user.


Code injection using packet modification

Yes, in the sense that you can forge and send such a packet.

First hurdle: is it still a valid packet? This depends on the packet structure. Many games leverage existing libraries that will use standard formats such as JSON or XML, so it will not be easy to forge a packet that contains the desired code and still be syntactically correct for the involved data format.

Then, will the server accept the packet? Most game developers are wont to wonder what would happen if someone modified

"score": 999

in

"score": 999999999

While I suspect, from some leaderboards I see in Google Play, that not all developers gave this possibility enough consideration, the usual low level, low security, but fast method to stop 99% of wannabe "winnerz" would be to also include the hash of the value and of a client (== unsafe) secret:

"score": 99,
"hash": "ff24e8a1f3fddb010095102bce5a013c"

A member of the remaining 1% of gamers could easily override this by digging out the secret from the game binary, or even trying to bruteforce it out of same binary: most of the time the hash for such a simplistic scheme will be something like MD5("SECRET" + SCORE) or maybe MD5(SCORE + "SECRET"), and SECRET will be one of the entries in the binary string table, in clear.

So you send along the modified code with the appropriate hash, and it will pass muster.

If the defense is still tighter, its stage will be almost impossible to overcome, though: the game contains the server's public key and uses it to RSA-encrypt the score, not even bothering to send it in the clear.

You can ignore this difficulty if you know that the buffer overflow server side is in the code reading the variable itself, whether it is RSA encrypted or not (i.e., before it is even decrypted).

At this point you've managed to send a string to the server in the hope that it will do something with it.

If the server foolishly makes some hardcoded assumptions on the string length, that could be enough for a buffer overflow. You may have to whip up some ad hoc substitutions to avoid sending a code payload with binary zeroes, which are likely to disrupt the string copy operation, but it's doable (and has been done).

But now another difficulty arises. You have injected something somewhere in the process space of the server. How do you manage this to result in something "useful" (from an attacker's point of view)? It might very well be that all of the above only results in the server hiccuping, or malfunctioning for longer periods.


Replace forbidden characters function check python

$(whoami) should bypass the filter and executes whoami.


SQL Injection query error with backslash

MySQL’s comment syntax requires a whitespace or control character after the --:

  From a “-- ” sequence to the end of the line. In MySQL, the “-- ” (double-dash) comment style requires the second dash to be followed by at least one whitespace or control character (such as a space, tab, newline, and so on). This syntax differs slightly from standard SQL comment syntax, as discussed in Section 1.7.2.4, “'--' as the Start of a Comment”.

The additionally included character in your cases probably just prevents the removal of the trailing whitespace or control character required by MySQL.


RSA key recovery using sound - How does it work?

This attack is a form of side-channel attack against RSA. The full details can be found in a paper published by Adi Shamir (one of three authors) of RSA fame.

The attack essentially works because a computer emits different sounds when performing different tasks. Using this information, it is possible to recover information about the RSA key during the process of encryption or decryption. When the same plaintext is encrypted with different RSA keys, the researchers were able to discern which key was used in the encryption process. This is a form of key distinguishing attack.

The interesting part about this is that the researchers were able to pull off the attack using mobile phones. This is troubling because this attack does not require specialized equipment to pull off.

While this attack is strictly theoretical at the moment, it is still interesting as side-channel attacks have been responsible for many of the attacks against RSA in the past.

Mitigation

Like the Debian advisory mentions, this attack is fixed in the newer versions of GPG.

  For the oldstable distribution (squeeze), this problem has been fixed in
  version 1.4.10-4+squeeze4.

  For the stable distribution (wheezy), this problem has been fixed in
  version 1.4.12-7+deb7u3.

  For the unstable distribution (sid), this problem has been fixed in
  version 1.4.15-2.

Better yet, use the GPG 2.x branch which already employs RSA blinding that should protect against side-channel attacks.


How to change personal cipher/digest preferences of existing OpenPGP key in GnuPG?

OpenPGP Algorithm Defaults

These are the algorithms you prefer others to use when they send encrypted messages to you. To print and change those settings, use gpg --edit-key [key-id]. You can list the settings in a more readable way without looking up the algorithm IDs in RFC 4880 using showpref
, and set it afterwards using setpref.

Changing Defaults

setpref cannot change only some preferred algorithms (like only digest algorithms), you have to list all three categories at the same time. If you omit some, it will fall back to the most universal defaults which all OpenPGP implementations following RFC 4880 are required to offer.

An example line proposed again and again is

setpref SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed

Minimum Required Set of Algorithms

But be aware, that GnuPG will automatically add 3DES, SHA1, uncompressed and those are the minimum set of algorithms all implementations must or should support. If you don't choose any compression algorithm, also ZIP will be added to the list. You can observe this default setting by setting any of those as preference, and nothing else:

gpg> setpref uncompressed
Set preference list to:
     Cipher: 3DES
     Digest: SHA1
     Compression: Uncompressed
     Features: MDC, Keyserver no-modify

Defaults might be different based on compliance options used.


What security implications are there when sending video feed over unknown applications, and how can we protect ourselves?

So I am not exactly I sure I understand the question because you mention this video feed is over unknown applications.  So this is what I think is happening and sorry if I get it wrong.  The University wants you to video yourself taking tests and working one certain material.  This feed should be sent out through a known application, although it may not be known to you, to the University in order to ensure your roommate was not typing in the work.

There are always security concerns, however taking proper precautions should be fine.  For instance I have heard of hackers using a web cam to spy on people however in order to do this they need the physical device connected and when I had to do the same as you for online tests I would connect it, all other times I would disconnect it.

It is important to realize however that if someone has control of your web cam there is a good chance they have control of your computer.

As far as sending the video to the University there probably should not be any sensitive information going to the University, well anything anyone but the University would want.


Yes, for sure. This is called a hybrid cryptosystem.
The general scheme is: create an RSA public / private key pair and encrypt the private key with the password. For this you can use password based encryption (PBE). Make sure you use a good KBKDF (more commonly known as password hashing) with a high work factor / iteration count.
You can now generate random AES data keys to encrypt the data. Encrypt these AES keys using the public key of the key pair and store them with the data. If you need to decrypt, decrypt the private key with the password, decrypt the data key and finally decrypt the data.
This is a very common scheme though, which has been used by e.g. OpenPGP for decades. It is still considered secure for in-place encryption. If you need something more secure, you should explain which part of above protocol you consider insecure. There is really no known way of enhancing a protocol already considered secure.
If you want to create something special, use post-quantum cryptography instead of RSA. You could also use only modern constructs such as RSA-OAEP or RSA-KEM and AES-GCM (use GCM with care though, for large files / large number of files).


How often are you attacked by an IP-range scan?

I can't comment on Windows XP as such but I can say that if you add a new connection to the internet, common ports will start being scanned certainly within 30min and sometimes within seconds.

This is not theoretical but actual.

As for XP getting a trojan, that is perhaps a little less likely unless you were to connect up an unpatched version of XP - maybe one that had been offline for a couple of years. But I've not tried it so I can't say for sure. If you have the kit lying around, why not try it?


You should describe problems in detail. For example, what algorithm was used to encrypt the file.

If you encrypted the file with a key-file using a strong encryption algorithm you won't be able to decrypt the file without this key-file. The password for the key-file won't help you if you don't have the file. This is a kind of two-factor authentication.

You can not regenerate the key-files. They are generated with random numbers. It is good that you cant regenerate them. If you would be able to do this an attacker could be able to.

The only way you can get back your files is trying to restore the key-files. If you are lucky you are able to restore them from your hard drive.

Your lesson learned should be to back up your keys.


TLS connection to untrusted server - client reaction for dropping connection standardized?

X509 certificate validation is covered in RFC 5280.

Look at section 6 (https://tools.ietf.org/html/rfc5280#section-6)

  Conforming implementations of this specification are not    required
  to implement this algorithm, but MUST provide functionality
  equivalent to the external behavior resulting from this procedure.


Terminology: What's the appropriate term for the digest output of various integrity hash and HMAC functions?

MD5, SHA-1, SHA-256, SHA-384, SHA-512 are examples of methods for message authentication using secure hash functions. When you apply the hash function on the message, you get a "Message Digest". [W. Stallings - Network Security Essentials, 5/e]


What are the best reasons you've heard for not implementing security?

I discovered a vulnerability in one client's infrastructure which could cause an outage plus data loss. When pressed for a 1-off cost calculation the client agreed it could cost them upwards of £1 million each time, so I proposed a remediation plan which would have cost under £100k.

They turned it down, as £1 million was below their lower risk threshold - they had bigger risks to set their teams on.

But a valid risk decision by the business is a correct answer to go back to a security team with, so this was fine.


What's the correct term form a pre-computed table with password/hash pairs?

If there are the entire hashes for each password it's a pre-computed hash table, in a security context it's usually called just hash tables.

If you have a strcture such as:

End of hash1 -> Password1, Password2, Password3, ...
End of hash2 -> Password4, Password5, Password6, ...

Then it's called a rainbow table, the main difference here is that you group all the passwords that produce hashes that have the same ending (For example, the last 32 bits of sha256). This is done to save some space at expense of computing time, in this case you take the hash you are trying to crack, look at the ending and try the passwords you have associated to that hash ending

Finally, hash tables (AKA Hash maps) in the context of general computer science is a data structure that uses a hash function (Not necessarily a cryptographic hash function) to store, order and/or access data in an array. It works like this:

k = Hash(object.id)
Array[k] = object

When you want to search an object in the table you just get the Array[Hash(object_id)]

There are also certain hash maps that allow multiple values for the same hash (In case of collisions), in this case each entry in the array is a linked list


What is blind injection and how to simulate the issue?

As the name implies, the technique injects SQL, but while being "blind": In response to the request, you won't receive an error message that displays the presence of the SQL injection vulnerability, such as:

  Unclosed quotation mark after the character string ' '.

The fact that you can't deduct the presence of the vulnerability doesn't mean it's not there.

A common method to test for this is to let the server impose a delay in responding: If the server responds immediately, it is not vulnerable. If it takes more time (say, 10 seconds), it is vulnerable.

OWASP has a great page on it, and (much) more information is available on SlideShare  and on the InterN0T forum.


Is this a scam? If yes, how does it work?

I think this is a very novel way to send spam.

The gmail account listed basically has set some ad text as their display name and you as the backup email. This can be done very quickly via APIs and will obviously trigger Google to send you an email from their domain (which most spam filters will trust).

No doubt Google will quickly ban the account/API key, but the attacker can trivially open/hack another Gmail account.


Any small idea to decode this algorithm from PHP script

The user and campaign IDs seem to be hexadecimal numbers (of 32 and 48 bits respectively).  I see no obvious structure in them — they're definitely not printable ASCII byte strings.

The 24-char "result" strings are not hexadecimal, but they might be base 36. However, if so, they're too long to be reliably decoded by PHP's base_convert() function.

However, if you look carefully at the sample strings, you'll notice that letters only appear in odd-numbered character positions.  This suggests that the strings might be encoded two characters at a time.  In fact, if you split each string into two-character pairs, swap the letters in each pair and decode them as base 36 numbers, all the values turn out to be less than 256.  Specifically, the strings you gave decode to the following hexadecimal strings:

z264643413z2e4l5i5744413 -> 6b 96 96 93 6d 6b 9e c9 c6 97 94 6d
x2v2d4a4a4z2d464j5c464u2 -> 69 67 9d 9a 9a 6b 9d 96 c7 9c 96 66
z2q274k523647454b4948464 -> 6b 62 97 c8 6e 96 97 95 9b 99 98 96
13s2j55433x2m5n594u244a4 -> 6d 64 c7 95 6f 69 ca cb 99 66 94 9a
74t2c4h5w20364j56474t254 -> 97 65 9c c5 68 6c 96 c7 96 97 65 95

These still show quite a bit of redundancy; for example, the upper nibble of each byte is always 6, 9 or c = 12, and the lower nibbles aren't exactly uniformly distributed either:

0 =  0:  0
1 =  1:  0
2 =  2:  1 #
3 =  3:  1 #
4 =  4:  3 ###
5 =  5:  6 ######
6 =  6: 11 ###########
7 =  7:  9 #########
8 =  8:  3 ###
9 =  9:  5 #####
a = 10:  4 ####
b = 11:  6 ######
c = 12:  3 ###
d = 13:  5 #####
e = 14:  2 ##
f = 15:  1 #

In fact, plotting the frequency of all bytes as a table, with the upper byte as the row (showing only rows 6, 9 and c for brevity) and the lower as the column, gives a curious picture:

  | 0123456789abcdef
--+-----------------
6 | 0010122112041311
9 | 0001238512312210
c | 0000011311110000

However, I can't immediately think of what might be generating such a byte distribution, but it does seem too distinct to be just a coincidence.


How to create an Apple Installer Package Signing Certificate

A copy-paste documentation for myself. For more information about the certificate extensions, have a look at Apple Developer ID Certification Practice Statement.

Create apple.conf with the following content:

[ req ]
distinguished_name = req_name
prompt = no
[ req_name ]
CN = my-test-installer
[ extensions ]
basicConstraints=critical,CA:false
keyUsage=critical,digitalSignature
extendedKeyUsage=critical,1.2.840.113635.100.4.13
1.2.840.113635.100.6.1.14=critical,DER:0500

Generate the key:

openssl genrsa -out apple.key  2048
Create the self-signed certificate:

openssl req -x509 -new -config apple.conf -nodes \
-key apple.key -extensions extensions -sha256 -out apple.crt

Wrap the key and certificate into PKCS#12:

openssl pkcs12 -export -inkey apple.key -in apple.crt -out apple.p12
Import it into keychain with open apple.p12. Select "Always trust".
Use the certificate to sign installers:

productbuild --sign "my-test-installer" ...


You have pretty much hit the nail on the head, which is why for most organised crime online the key is to follow the money, which is much more traceable.

Depending on paranoia level an attacker could route through multiple proxies, use TOR or other anonymising tools and generally obfuscate to whatever degree they want, and whilst some ISPs will cooperate, a canny attacker will route through countries where they won't.

Have a look at the question on Anonymous and Lulzsec -
 Why is it difficult to catch "Anonymous" or "Lulzsec" (groups)?


Should I create a JWT on one server, and verify it on a different server?

What you want to achieve is authenticated machine-to-machine communication between the Lambda function and the websocket server.

There are different mechanisms to achieve that. Using a JWT token is one possibility, but there are even easier approaches, if you want to keep it as simple as possible.

Based on your question, you want your authentication based on a pre-shared secret scheme. The simplest solution would be using basic auth (or something equivalent, if you are not using HTTPS as your transport protocol). Whatever protocol you are using, make sure it is encrypted, otherwise your secret may leak.

The websocket server will first evaluate the basic auth credentials and decide, if the sender is valid and the request gets processed further. The credentials can be as simple as a sufficient long random string (e.g. 128 bit).

If there's no additional value for you using JWTs (e.g. you want to limit the lifetime of the token or transport additional information in the body of the token), I would recommend to keep it as simple as possible, as complexity may introduce hidden risks and vulnerabilities.


VCS to manipulate returned trees to prevent leaks?

Before this gets out of hand with the edits and the comments, I wanted to say this.

This is not a hypothetical situation. Almost all software companies face this problem, and it all boils down to a trust issue. This topic has been extensively discussed on other StackExchange sites, most of the answers can be summarized in:

  1- Hire people you trust.

  2- Make then sign an NDA.

  3- Give them access only to the code they need

I'll just expand on the last point to address the situation about which you're wondering. In the case of Windows, I'm 99% sure than not all Microsoft employees have access to the Windows source code. Not even the employees who work on Windows have access to all of the Windows code. Each employee should have access to the parts of code he's responsible of maintaining.

Developers on Project A don't need access to Project B's code, and so on.


How does google know if I am logging in from a new machine(using web browser)?

@Joe M.'s comment provides a good link as to how Google accomplishes this.

For what you are looking to accomplish simply capturing the IP address of the visitor seems like it would be effective in determining new or returning users, though this isn't enough, as multiple unique users could navigate to your site from within the same internal network (to your server this would appear as originating from the same external IP) and would need to be handled individually. If this was your only logic then you could only ever have 1 unique visitor per IP, which is probably not what you are looking for.

To handle this you would need to assign a unique cookie to each unique visitor. This works for Google because it will associate your username with this cookie. Unless you have something with which to associate the cookie (username, id, etc.) then it won't be possible because the requests could be spoofed by replicating request headers from another machine using the same external IP.

I suppose you could associate a WebGL fingerprint, which would be unique to the specific machine, and associate that along with the external IP for the cookie value.


How fast is it to bruteforce a 48-bit key with current technology?

A day, instantly.

48 bits are not an awful lot, also merely generating (which per se does not make a lot of sense) that many keys is very fast.
Even a naive single-threaded CPU implementation on a cheapish (not even remotely close to $1000) desktop computer could do that in a day or two.

In order to be meaningful, you must do something with these keys to verify them. It is explicitly mentioned "no hashing/salting" in the question, so one can safely assume that no expensive key derivation (think beecrypt or such) which artificially slows us down needs to be done.
I will therefore assume that you need to decrypt a block of AES and compare the result to a known plaintext.

This article claimed 11Gbps on a CUDA implementation 6 years ago, which would boil down to about 4 days for brute-forcing your 48-bit key. Assume that a rig with a current upper middleclass or high-class GPU is 3-5 times as fast, and we are at approximately one day for your $1000 budget (give or take a few hours, it makes no difference).

A $1M budget attacker could naively just do that same attack with 1000 machines, which would require a minuscule amount of communication between nodes (add some milliseconds) and place him at around 1 1/2 minutes, give or take a few secs.

If you however assume that an attacker with such a budget is serious about the attack, you must assume that something better is used. A HPC cluster comes to mind as the next naive solution, but why not invest in FPGAs?
If you are serious, you can easily get 10 or 100 times as fast than the "simply use 1000 desktop computers" solution for the same money.
Let's just assume 100 times faster, and we're at 0.9 seconds. Why assume? Well, because it no longer makes a difference at this point.

Practically, it doesn't matter at all whether an attack takes 9 seconds, 0.9 seconds, or 0.00009 seconds. They all fall under instantly. Anything you can crack in 9 seconds is doomed.


How can I prevent a man-in-the-middle (MITM) attack on my Android app API?

That app (and all MITM proxy apps such as SandroProxy and mitmproxy) work by installing their own trusted CA certificate on the device. That allows them to sign their own certificates which the device will accept.

You have to manually install their certificate to the user key-store using a dialogue such as this:

After which it displays warnings such as this:

It's unlikely (albeit not completely impossible) that a user would do this unintentionally, so overall it's a reasonably low threat.

Having said that, if you want to protect your App even if someone has installed a malicious CA certificate then you should implement certificate pinning.

If the device is rooted then it is conceivable that an attacker could install a malicious certificate, conceal it, and modify your Apps to compromise validation and prevent pinning. However, if something rogue has root access then essentially your entire device is compromised any way.


Mitigation Strategies for Response Spliting Attack

As to Response Splitting, vulnerable application allows injection at http response headers level. So there have to be an attack vector in app that allows unfiltered input to be appended to headers section of response.

Today frameworks (like .net or J2EE, and probably others) offer programmers an API which can be used to mitigate/eliminate such attacks (in server side code). But as we all know "It's impossible to foresee consequences of being clever", so developers can avoid those protections entirely, leaving application vulnerable to such attacks.

So there isn't a strict yes/no answer. It depends on developers imagination.


In a wireless network which is the Radius client, the switch or the wireless access point?

Whichever is acting as the "Authenticator" (https://en.wikipedia.org/wiki/IEEE_802.1X#Overview).

  The main parts of 802.1x Authentication are:

  A supplicant, a client end user, which wants to be authenticated.
  An authenticator (an access point or a switch), which is a "go between", acting as proxy for the end user, and restricting the end
  user's communication with the authentication server.
  An authentication server (usually a RADIUS server), which decides whether to accept the end user's request for full network access.

https://kb.netgear.com/1209/What-is-802-1x-Security-Authentication-for-Wireless-Networks

From this it looks like you can have the switch authenticate the access point (to prevent someone plugging in a different access point) but that the access point itself could be authenticating the clients too.

The switch would likely only authenticate what is plugged into it and I doubt would be wireless client aware.

See also : Does WPA2 Enterprise also authenticate clients to the 802.1X protected switch port?


Is there a virus that attempted to foil generic decryption techniques, and how did it do so?

Thanks for the link, it is an interesting question indeed. I'm not a virus expert, but I know from previous reading I know that from the document you mention, I have a problem with the sentence "Inside this virtual computer, program files execute as if running on a real computer" which merely sounds like marketing simplification to my hear.

Indeed, the issue with this system is that if the anti-virus would have to implement a full fledged virtual machine to run the virus in an undetectable sandboxed environment really implement a full computer environment, then it would be really too resources intensive. Therefore, the anti-virus designer have to find a compromise: which system call should be implemented, which should be just stub, what kind of values should be returned, etc.

Starting from that, the virus designer will rely on these assumption to try to detect:

When the virus code is run from within the anti-virus sandbox (trivial example: call some system function several times and compare the results which should be different on a real system, and are always the same due to anti-virus' sandbox stub), in this case it will not trigger the decryption algorithm and remain undetectable,
When the virus code is run on the real system, in this case the virus will trigger its load.

And the next logical steps are just an arms race. Anti-virus vendors try either to fool or recognize the virus' sandbox detection routines, and the virus designers try to find different alternative ways to detect the sandbox, and so on...

Edit: Interestingly enough, the document goes on and acknowledges the speed issue affecting the ideal "as if running on a real computer" model ("the key problem with generic decryption is speed", page 8). It then replaces this ideal model with an heuristic one, concluding with the "marketing version" of the arms race I mentioned: "heuristics demand continual research and updating".


Chrome ( and most likely Firefox ) already prevent execution of scripts when they are given in for example the URL parameter, maybe even other things like a request body, and then proceed to give you a warning.

See also Does Google Chrome protect against cross site scripting (XSS)?

Also when you search for XSS prevention in the chrome extension store, you will get results.


Taking credit card info online recommendations

We have e-commerce sites, all interfaced with paypal.com. When the customer types in his CC info, he's actually on paypal.com and not our domain, through a Paypal API.

They have many options. One is at https://developer.paypal.com/docs/integration/web/. Check it out and give them a call. We are a longtime and happy Paypal customer.


Why are triggers not often used to secure a database?

I think what is being talked about are "Stored Procedures". Triggers are fired internally in the database when actions are performed, but stored procedures are direct parameterized functions.

  Why are triggers (stored procedures) not often used to secure a database?

Sometimes laziness, sometimes it's just too restrictive. It's also the case that using parameterized SQL queries in your code also prevents SQL injection attacks. Jeff Atwood wrote a decent article about tradeoffs with stored procedures back in 2004.

That said, even with parameterized SQL queries, stored procedures still have a place in my mind, especially with passwords. There is no good reason for the application to ever query the password hash from the database system, only to ask the database system to compare an input value (such as a generated hash to keep the load off the DB server) against the hash. For that scenario, a stored procedure definitely adds security and I really wonder why nobody ever uses that.

  Wouldn't that be much easier to make a trigger check for injection

Well, let's consider this: if your trigger can check for SQL injection, then I presume your code could as well. Then you either have a whitelist of values, or a blacklist for detection. Blacklists are poor choices. Even then, if you're doing whitelists the enumeration factor could be immense if you don't trust any of the query input at all, including the structure. Then we're back to either writing a stored procedure for every possible operation or using parameterized queries... and generally, the second method is saner.


What type of activity at the WAN port of router can cause massive data uploads, when no devices are connected?

You provide few informations. Have you checked the log of the router to see which IP and with which protocol the upload takes place?
You should then check that you have not enabled remote assistance and that the firewall:
- block access on any port and protocol from the outside to the inside.
The installed firewall should be stateful, so if you don't allow open connection access from the outside, you can feel comfortable.
- Open external access only for the ports and protocols in use by the hosts inside your network.
The administrator password has nothing to do with WPA and WPS. You should change it often and do it with the device connected by cable for more security, not wirelessly.


While I am sure there are, in fact, firewalls that may do that, I am not off-hand aware of any that operate this way. There are packet spoofing detection mechanisms, although they tend to act a little different.
Bogon Filters
A bogon is defined as bogus IP address. Specifically, it is the list of all IP addresses that have not been allocated by IANA, by a delegated RIR. The best way to get this list is for your firewall to support subscribing to a bogon service. If you enable bogon filtering on your firewall it also tends to also include ingress packets where the source address is listed as an RFC 1918 address.
It is also customary to block using the same rule, or locally edit your bogon list, to include your local allocation. It is generally considered unlikely that your internal IP addresses will be seen on the ingress port of your firewall. An exception to this would be any equipment of yours that exists outside your firewall. This would most likely include packet shapers, routers, or other infrastructure equipment, but in some cases other equipment may purposely be left external. Make sure to exclude those from the bogon list.
MAC Limiting
For devices like border firewalls we generally have a really good idea what physical devices are able to directly communicate with them. This should, again, be infrastructure devices like packet shapers, routers, etc. If you have a DMZ then you may also see those devices in there depending on your architecture. In this case we can enumerate the MAC addresses that should be able to talk directly to the firewall and deny any that aren't on that list. Incidentally, this also helps catch systems that end up on this network segment that shouldn't.
For firewalls that may be deployed for departments, or in a transparent/bridge mode within a network for segmenting a subset of hosts, building these lists can be a lot harder.
TTL Analysis
Between two hosts the number of hops generally remains constant, or changes very little, between packets. As such if the TTL dramatically changes from one packet to another this could easily be a spoof attempt. This does require keeping more state information, and is not fool-proof since the route could change, but is often indicative enough.
Route Checking
If you have multiple active uplinks then you can also verify that the packet is coming in on the correct interface. There exists a standard for this called Reverse Path Forwarding (RPF). In short every time a packet is received on an interface the router checks its routing tables and determines if that is the correct interface for that source address. That is, if the routing tables say that packets destined for 144.152.10.0/24 are transmitted over interface ge-0/0/18 and it receives a packet from 144.152.10.5 on interface ge-0/0/20 then it is probably spoofed and should be dropped.


Different results with NMAP: filtered + tcpwrapped

Your "bulk" scan of many IPs has probably triggered a firewall or IPS to drop your probes instead of letting them through. The pattern of "try to connect to lots of different IPs on the same port" is easy to detect. This is most likely the cause of the filtered port state. Slow down your scan until you do not cross the threshold that the IPS considers as "lots."

In the first scan, Nmap did not try to probe the services, but only to determine the state of the ports. Because it did not try to probe the service, it lists the commonly-used service name for that port number, found by looking it up in the nmap-services file. This is the source of the "ftp" and "ssh" labels.

In the second scan, the -sV option tells Nmap to go ahead and try to get a response from the service in order to classify it. It may be that someone is using port 21 to run a web server and not an FTP server. When it tried to do this, the target immediately closed the connection. This behavior is commonly evidence of a program called TCP Wrapper, which hangs up connections like this if the remote IP (yours) is not on an approved list. Other network devices may cause similar results, but the tcpwrapped string will still be shown. Nmap no longer uses "ftp" or "ssh" for these ports because a simple FTP or SSH server would not behave this way.

I recommend slowing down your scan a bit to try to avoid detection, and adding the -v --reason options to see the reason and received TTL field value for each port. Comparing these can give an idea of where the response (or no response) is coming from--the target or something between you and the target.


How to store an user access token on a third party site in the front end

That token should be set by your back end server, not the wordpress site that is using your plugin.

If your server then sets httpOnly when issuing the cookie, requests (for example via JavaScript from the wordpress site that uses the plugin) to your backend would have that cookie included in the request by the browser while the javascript itself (from the wordpress page) will not have access to it.

From the OWASP:

  If the HttpOnly flag (optional) is included in the HTTP response header, the cookie cannot be accessed through client side script (again if the browser supports this flag). As a result, even if a cross-site scripting (XSS) flaw exists, and a user accidentally accesses a link that exploits this flaw, the browser (primarily Internet Explorer) will not reveal the cookie to a third party.

After all, your question implies that you didn't think your communication model through all the way; this information does never need to be accessible from the scope of the wordpress blog.


The Postfix master process is the one that launches the other daemons. In particular, it launches the daemon that delivers mail locally; the latter must be able to impersonate any user ID in the system, which involves beginning its life as root. Thus, it is mostly unavoidable that the master process runs as root; otherwise, it would not work at all.

Moreover, the "risk" involved in running things as root is often overestimated. For instance, on my own server, what I fear most is that my machine would be subverted and used as a relay for attacking other people. Whether an attacker gains root access or only a "normal user" access does not change things much in that respect.

There is a widespread habit of turning root daemons into non-root daemons, and then to rejoice at the "security improvement". The improvement is real in the mainframe scenario, where many users have shell accounts on the same machine, and the attacker is one of these users, intent on gaining access to the files of other users. However, the mainframe model has mostly disappeared (it used to be prevalent in universities, but nowadays every student has his/her own computer to play with). When machines are "personal" (e.g. you have your own server and no hostile individual has an account on it), the benefits of running some daemons under a non-root UID are slight. It does not harm by itself, but it does not justify going out of your way in complex ways to "fix root daemons".

What makes Postfix daemons secure is absence of buffer overflows or similar vulnerabilities; running as non-root is simply a way to mitigate consequences in case a vulnerability was present and exploited by an attacker; and the mitigation does not gain much when the machine is not a shared mainframe.


Opinons: To report or not to report? CFAA vs the White Hat

With respect to how (and whether) to disclose vulnerabilities, that subject has been covered extensively already on this site.

With respect to dealing with a potentially-embarrassing flaw with a powerful organization, remember this little gem:

Powerful organizations do not like to be embarrassed. And one way for them to save face is to incriminate the messenger ("see, we're not irresponsible, he's a terrorist"), and so when doing so, some certain amount of self-protection is in order. Perhaps you should remain anonymous. Perhaps you should seek legal counsel. Perhaps you should work through a third party (e.g. security firm).

Certainly what you should not do is flaunt the vulnerability in a spectacle of  sarcastic derision and self-promotion. It may be safe to poke the bear with a long enough stick, but the only way to know for certain is in a post-mortem analysis of the events. Probably best not to poke the bear if you want to stay on the safe side.


Anti-skimming techniques are just a subset of anti-fraud techniques. Anti-fraud in ATMs is the collection of defense mechanism against payment card fraud. It includes anti-skimming devices, cameras embedded in ATMs, measures to prevent shoulder surfing, etc.

Anti-skimming devices in particular are devices installed on or embedded in the ATM. They prevent the illegitimate copying of the payment card information.


Facebook Knows About my Search History in Other Browsers

The answer to your question is "Super cookies"
The trick is about HTTP Strict Transport Security (HSTS) for something it wasn't intended for. HSTS is a modern web feature that allows a website to tell a browser it should only connect to the site over an encrypted connection.

Which makes the cookies for that website work even when you're in icognito mode.

For more information read those references:

Ref_1  | Ref_2 | Ref_3

This Answer is for your question

  "Is there some other mechanism that I don't know?"

But regarding your ISP, I think things are more terrible than storing a cookie :D
And about your question:

  "How did facebook get this information?"

The Method i Told you about. And never forget that facebook stores the search history in their database, so that also may be used in advertisements so make that in mind too.


Yes. Set up whatever mail server you use to filter mail based on destination. This is trivial.

For Postfix this is solved with the check recipient access table configuration directive, which lets you configure either a system wide, or per user allowed destinations. For different MTA's there's different options.


what is the relation between ISO IEC 15408 and Protection Profile?

Answer to 1. The table gives an overview of which security assurance components (SARs) are included (must be included) to meet a certain EAL level. Suppose you are writing a security target or protection profile targeting EAL4. Then you take a look at the column for EAL4 and screen each row. The first row is for ALC_TAT, and the entry in the EAL4 column is 1. This means that for EAL4, the assurance component ALC_TAT.1 will be included in the evaluation process. If you want to know what that means for the product developer and the evaluator, you can scroll down to page 151.

Among other actions, the developer has to ensure this for example:

ALC_TAT.1.1D The developer shall provide the documentation identifying each development tool being used for the TOE (target of evaluation, i.e. product).

The evaluator has to also do things, like for example:

ALC_TAT.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

Including ALC_TAT.1 means that also all dependencies must be included as well. ALC_TAT.1 has a dependency on ADV_IMP.1, for example. An EAL level makes sure that all dependencies are met and everything is consistent including all potential circular dependencies. For example if you take a look back in the row ADV_IMP and column EAL4 you see a 1, i.e. ADV_IMP.1 must be included as well. Thus the dependency is met.

Note that SARs are stacked hierarchically, where each hierarchy level adds some more requirements. One can also "overachieve" the EAL level. For example including ALC_TAT.2 instead of ALC_TAT.1 would mean for the developer:

ALC_TAT.2.3D The developer shall describe and provide the implementation standards that are being applied by the developer.

When you include SARs that are not needed/higher than a predefined EAL level, one usually adds a + at the end. For example EAL4+ could be EAL4 but ALC_TAT.2 instead of .1, as well as all dependencies that are introduced by ALC_TAT.2 but are not required for ALC_TAT.1. In this case, the depencies for ALC_TAT.2  and ALC_TAT.1 are exactly the same, namely only ADV_IMP.1.

Answer to 2. The PP includes the security functional requirement component (SFR) FCS_CKM.1 . This component is defined in part 2 in CC in the chapter Class FCS: Cryptographic support. FCS_CKM is the family, then the component is leveled into 1, 2, 3, and 4. If you include FCS_CKM.1, then the only subcomponent is FCS_CKM.1.1, and hence this is included in the PP. This leveling and subdividing components is similar to the approach for security assurance components (SARs), defined in part 3. But don't mix

SFRs (describing requirements on what is subject to evaluation in the product) with
SARs (describing the depth/extent of the evaluation of the security functionality described by the SFRs).

Answer to 3. A protection profile is a description of the target of evaluation together with a fixed combination of SARs and SFRs, where all dependencies among these are met. The set of SARs could be

implicitly defined by just choosing one EAL level - then the set of SARs is defined by the table you mentioned in your first question.
The set of SARs could also be different, for example choosing an EAL level and augmenting the EAL level with additional SARs, or
simply directly choosing a set of SARs which are consistent.

Approach 3 is used in the protection profile you refer to. If you take a look at the table you mentioned in your first question and the list of SARs in the referred protection profile, you can see that not all SARs that are needed for EAL1 are included. So looking at this from a EAL level, this PP is EAL0+, where the + is ADV_FSP.1, AGD_OPE.1, AGD_PRE.1, ATE_IND.1, AVA_VAN.1, ALC_CMC.1, ALC_CMS.1.

This is the general approach with PPs. As mentioned, collaborative PPs don't adhere to the predefined sets of EALs and usually define their own sets/combinations of SARs in one PP with ignoring the preset EAL levels. This has advantages and disadvantages: The cPP approach allows to leave out SARs that are not relevant for the specific product type/industry segement, or are difficult to meet due to involved costs. From an end-users perspective the disadvantage is that you have to know the underlying cPP and involved SARs to assess whether the product is actually secure. Whereas in the standard approach you know that for say, EAL level 4 you will always have a thorough vulnerability assessment (AVA_VAN.3 or higher).

The result is that in practice the cPP approach is usually used mostly for low-security products (some kind of "network device") where the product-development cycles are short, whereas high-security products with a longer development cycle often still fix an EAL level (i.e. typical smartcard chips are usually EAL5 or higher).


Handling Authentication without a unique username or password

oAuth has been designed to be able to authenticate a user against an external service (plus other extras like getting some useful information about that user form the authentication platform). So you would get the information you need.

This said, this is primarily an end-user construction, requiring an interactive session.

There are derived mechanisms like JWT which could work better in your case (since you mention POST and API I believe that there will be no interactivity).

But you could simply generate on demand unique tokens with a large entropy  and use them for persistent sessions (it is difficult to call that "authentication" as you do not have any challenge). This is basically a restricted usage of web cookies (you could leverage the libraries you already have to generate them).


Feasibility of infecting notebook BIOS with virus?

It is feasible. It is true that the BIOS requires a very "low level" or deep understanding of machine code and the actual hardware systems themselves. It's possible he could have written one... but much more likely he could have -found- one and installed it.

Wipe/reinstall the BIOS. This may or may not be possible based on your vendor. If you can fully re-install, do it. Also, most likely if you do have something, it calls files on the drive. Check out this article: https://www.theregister.co.uk/2011/09/14/bios_rootkit_discovered/

-Then do not turn it on- Take the hard drive out and put it in another computer and wipe it. Do not boot from it.  Then reinstall ubuntu. It is possible that the virus will re-install to the bios from the hard drive.

But before all of that, if you think your computer is being "monitored" I would highly suggest reviewing your outbound connections. It will have a "shell" that calls out to some server on the internet to give the info to the monitoring computer. Monitor these outbound connections and if you can verify them all, you're probably fine. https://kb.iweb.com/hc/en-us/articles/230267788-Detecting-Malicious-Processes-in-Linux

Also that's an old computer; might be time for an upgrade anyway. Piece of mind is nice.


What can I do to get rid of spam emails that come from different, randomized email addresses?

The apparent "FROM" is readily faked. Look at the full email headers for several of the spams, odds are good there is a common identifier buried inside that you can use as a filter, it may even be as simple as the originating IP.
Don't forget that your filter need not be an EQUAL match. You may find that a substring match using CONTAINS will work best.


How to ensure wildcard certificate private key security?

I'd configure a reverse proxy with SSL decryption capabilities. Therefore the cert is put in a single server and it terminates the SSL/TLS connection.

Your private key will only be on one server and you'll also have the ability to inspect HTTP traffic using a IDS/IPS.


Yes, there exists algorithms that hide messages inside messages that can look quite innocent. Take for instance spammimic. It gives the possibility to hide your message inside a typical looking spam message.

A google search for "Steganography hiding text in text" gives you more research and examples around this.


What technologies to use for the "front end" server to safely validate requests?

From the security standpoint any common programming language will do as long as you are familiar enough with it to securely code in it. Some languages like make this harder but often run faster, others make it easier at the cost of being slower. But the main point here is your expertise.

If your goal is to handle well-formed JSON with a fixed schema Go might be a useful language since it makes it easy to map JSON to structures with clearly defined types. This allows you to unmarshal JSON to a structure and marshal it back to JSON and implicitly normalizing and sanitizing the data while doing this. Go has also integrated support for handling HTTP and scales well. But there are likely libraries for other languages which provide similar support and it might be better to use the language you are deeply familiar with instead of learning a new one.


Can someone bypass/recover/access data to Hard-Drive when Password Protected?

BIOS hard drive passwords are implemented using a "lock" mechanism in the drive controller itself. When the drive has a password set, the controller "locks" itself and will not allow the data to be read without being "unlocked." However, this can be bypassed by an attacker who replaces the drive's controller board with another (unlocked) board of the same model, or, depending on the controller, by resetting or erasing the password through a model-specific (usually undocumented) hardware or software mechanism.

A BIOS hard drive password is not the same as encryption, and should not be used as a defense against anything more than casual attacks by unskilled attackers.


Connecting to the remote site on port 443 is pretty much all you need to do.

If you have a web site running on the default port at a given host name, then it will use port 443 for HTTPS. If the web site does NOT use the default port there is no way to know what port will be used for HTTPS (if any) except attempting a handshake on every possible port: that far too slow for proxying and might get you locked out by IDS.

You might also want check the answer to "how does TLS works" which describes the handshake in detail.


You can use tcpdump for TCP/IP sockets

Unix domain sockets are something else.


Is there a way to add salted hashing to my user authentication without breaking my former login server

You have conflicting requirements here. The compatibility requirements forces you to keep the old hashes. The security requirements forces you to drop them. You will have to make a choice here about what requirements to fulfill.

If you decide to keep the backwards compatibility, try making the best out of a bad situation:

The old hash and the new hash should be stored in different tables, and the database user that the web application uses should not have read access to the old hash. Use table and/or column permissions for this.
As soon as you no longer need the old application, drop the table with the old hash. Ashley Madison famously failed at this point - they upgraded to bcrypt, and then for some idiotic reason they left the old MD5 hashes lying around in the database. When the database was leaked, that fancy bcrypt did not help much...

Or, alternatively, if you are not afraid to create a bit of a mess:

Drop the old hashes. In the new application, add on option "Create temporary password for old application". It gives you a long, random password that is hashed in the old way and only kept in the database for X minutes. The user can then logg in to the old application, and the password is then automatically deleted.


Do OpenPGP/GnuPG apply slow hash to password when encrypting/decrypting key?

Yes.  When encrypting a file using a passphrase, they should use a slow hash function to derive the cryptographic key from the password.

Yes, GPG already does do this.  See my answer that explains elsewhere how to use GPG with a slow hash, if you need to encrypt a file with passphrase-based conventional encryption.  The short version is that I recommend using the following command-line flags:

gpg -c --force-mdc --s2k-mode 3 --s2k-count 65011712 personal.zip

This asks GPG to use a slow hash function for hashing the password.


A quick fix against CSRF is to check the Referer and/or Origin HTTP header. At least one of these should be set and the domain it contains should be your domain (i.e. same origin).

Note that this will break cases where your site is accessed from a bookmark, link inside a mail or similar since in thus cases no Referer will be sent. But in no case you should simply accept an empty Referer (unless you have a non-empty Origin header) since this is easy to create for an attacker.

You should also make sure that your checks for the domain are correct. This is, if your site is www.example.com you must not accept Referer like http://www.example.com.attacker.com or http://www.attacker.com/www.example.com or http://www-example.com.

You should also make sure that the attacker can not use other functionality (or bugs) in your application as a trampoline to create a custom request with malicious payload but the expected same-origin Referer. As Arminius nicely pointed out in a comment, open redirects might be such a trampoline. Thus you should either make sure that all requests to the domain have a same-origin Referer or that any parts which might need to accept a cross-origin Referer can not be abused as trampoline.

For more information about this method of protecting against CSRF and about its potential problems see Verifying Same Origin with Standard Headers in the Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet from OWASP.


Is my sons' school portal in violation of any Password/UserID rules?

It certainly doesn't sound like best practice, but I'm not sure if it necessarily is violating any laws. I'm guessing you are from the US, so there are data protection laws, but they aren't as defined as we'd like - same as in the UK the guidance tends to use words like 'appropriate protection'.

You should be able to use the argument that if they continue to send paper mail or emails which have both username and password, they could end up suffering not only a big fine, but also have considerable reputational damage. Depending on which state you are in - some require public disclosure of sensitive information, but even if not, parents will pass the word around!

The expectation should be that two messages would have to be intercepted in order to get unauthorised access. And it would be even better if one was by USPS and one by email, thus requiring an attacker to compromise two forms of communication, but that could be overly complex for a school.


What is it that makes public wifi so insecure?

Many public access points have no security at all. This means anyone within range (and with the right antennas and amplifiers that can be several hundred meters) can read all traffic.
Many of those that do use WPA2. Anyone with the password can decrypt all traffic.
Even if your traffic was safe from other users do you trust the owner of [random cafe] not to read or mess with your traffic?
With a device like a WiFi Pineapple you might not even be connected to the network you think you are.

3G/4G wise data traffic is encrypted with a per user key. Although it has its own problems - see my answer here.

With any network you do not fully control you should use a good secure channel over the top - for web access either HTTPS/SSL (remote server identity verification and hides content but not who you are talking to) or a VPN.


How was the website able to tell my credit card was wrong before it processed it?

Credit card numbers can verified by calculating a checksum.

Every credit card number created is assigned a number following an algorithm.

  Ross Millikan:
  The checksum specifies the last digit, so there are 15 digits left.
  That should mean there are 10^15 numbers available, but there are
  other restrictions. The first digit is the card type (4=Visa,
  5=MasterCard, etc.) and the next several have to do with the issuer.

Following that, if this a credit card number does not comply with the algorithm, the checksum is incorrect so the number must be invalid.

The algorithm is called the “Luhn algorithm”, check this Wikipage for more Info.

  TripeHound: Note: if a given number fails the check, it is definitely
  not a real CC number. However, if it passes the check, it only proves
  that it is a potential CC number: it does not prove that it has
  actually been issued. The next stage of verification (talking to a
  card-processor) should verify that. Similar checks can be made on UK
  sort-code/account-number pairs (and probably something similar in
  other countries) and on International Bank Account Numbers
  (IBANs)

Edit: Added some of the information given in the Comments to the Answer.
Pleas go and give them an Upvote too, its great information.


I think your effort is broken by design. You want to install a program at someone's machine that connects to an FTP server via password, but you don't want the user to know the password. No matter what you do to protect it, the user can easily intercept the network traffic comming from the program. For example, the user could set up a proxy and just dumping everything that runs through it - the password will be somewhere in this dump. Encrypting the password at the user's side and decrypting it at the server will just delay the problem - the user will just send the encrypted password.

I would rather set up an extra FTP account with an extra directory just for this user. There he cannot hurt anything, because anything he sees is generated by his own actions.

edit It's true that with FTPS the user wouldn't be able to extract the password. But who is setting up the encrypted connection in the first place? The user's machine. So the certificate is sent to the FTP server before the encryption is done, which can be intercepted again and used to decrypt the whole communication.


Multibyte character exploits - PHP/MySQL

Summary. Yes, the issue is that, in some character encodings (like UTF-8), a single character is represented as multiple bytes.  One way that some programmers try prevent SQL injection is to escape all single quotes in untrusted input, before inserting it into their SQL query.  However, many standard quote-escaping functions are ignorant of the character encoding that the database will use and process their input as a sequence of bytes, oblivious to the fact that a single character might fill up several bytes.  This means that the quote-escaping function is interpreting the string differently than the database will.  As a result, there are some cases where the quote-escaping function might fail to escape portions of the string that the database will interpret as a multi-byte encoding of a single quote; or might inadvertently break up a multi-byte character encoding in a way that introduces a single quote where one was not previously present.  Thus, multi-byte character exploits give attackers a way to do SQL injection attacks even when the programmer thought they were adequately escaping their inputs to the database.

The impact. If you use prepared/parametrized statements to form all database connections, you are safe.  Multi-byte attacks will fail.  (Barring bugs in the database and the library, of course.  But empirically, those seem to be rare.)

However, if you try to escape untrusted inputs and then form a SQL query dynamically using string concatenation, you may be vulnerable to multi-byte attacks.  Whether you are in fact vulnerable depends upon specific details of the escaping function you use, the database you use, the character encoding that you're using with the database, and possibly other factors.  It can be hard to predict whether multi-byte attacks will succeed.  As a result, forming SQL queries using string concatenation is fragile and not recommended.

Technical details. If you'd like to read about the details of the attacks, I can provide you with a number of links that explain the attacks in great detail.  There are several attacks:

Basic attacks on, e.g., UTF-8 and other character encodings by eating up extra backslashes/quotes introduced by the quoting function: see, e.g., here.
Sneaky attacks on, e.g., GBK, that work by tricking the quoting function to introduce an extra quote for you: see, e.g., Chris Shiflett's blog, here, or here.
Attacks on, e.g., UTF-8, that conceal the presence of a quote by using an invalid non-canonical (over-long) encoding of the single quote: see, e.g., here.  Basically, the normal way of encoding a single quote has it fit into a single-byte sequence (namely, 0x27).  However, there are also multi-byte sequences that the database might decode as a single quote, and that do not contain the 0x27 byte or any other suspicious byte value.  As a result, standard quote-escaping functions may fail to escape those quotes.