Prevent denial of service attacks against slow hashing functions? I've been thinking about bcrypt recently, and what I wonder is if there's a way to deal with the inherent (D)DoS problems with slow hashing functions. Namely, if I set up bcrypt so my machine takes 100 ms to hash a password, then it only takes 10 password attempts per second to make my server unresponsive. I could reduce the difficulty, but the faster I make it for me, the faster I make it for an attacker. I could ban anyone who tries too many passwords, but botnets are everywhere these days.

Are there any common solutions to this problem?

I was thinking there's probably strategies where you make the client do something complicated but easily verifiable, and check the result before checking the password, but it has a couple problems:

Is there a way to do it in plain HTML (without JavaScript).
What would the "something complicated" be? RSA encryption gave me the idea of generating two primes, multiplying them together, and asking the client what the original primes were, but I suspect the "generating two primes" step wouldn't be particularly fast either.

Another thing I had considered was caching bcrypt results in memory, so attacks against one user don't cause problems, but what if I have too many users to reasonably do that?

I'm mainly thinking of using this in the context of a username/password login box on a website, but any method of dealing with this could likely be done in JavaScript if there's nothing better.

EDIT:

The idea of somehow rate limiting requests is useful, but it's not the kind of solution I had in mind. It makes DDoS attacks more expensive (because you need more IP addresses), but it doesn't solve the fundamental problem that the server is doing significantly more work than the attacker(s).

An example of what I'm thinking of is how using a salted password makes rainbow tables worse than a straightforward brute-force attack. So if you're using salt, you don't have to worry about rainbow tables at all, since there's better attacks. What I want is a way to make attacking my login page no better (or worse) than just hitting random URLs.

One possibility is to consider using client puzzles.  The basic idea is to force the client to do a significant amount of work, and prove it has done so, before you will accept a username/password pair and try to validate it.

Here is an overview of the approach.  The server generates a random puzzle, and sends the puzzle to the client.  The server generates the puzzle in a way that it can predict reasonably well how much effort will be required to solve the puzzle (e.g., 100ms of computation).  The client solves the puzzle, and then sends the solution along with the user's username and password.

In a web setting, this would probably be implemented with Javascript: the login page would contain the Javascript code to solve the puzzle and the puzzle description.  A legitimate user's web browser would run the Javascript on the page, which would solve the puzzle and include the solution in the form along with the username and password.

This makes it harder for an attacker to DOS the server.  For instance, if it takes the server 100ms of computation to check the validity of the user's password, and if the server chooses a puzzle that takes 100ms to solve, then an attacker will have to do at least as much work as the server.  If you turn up the dial to select puzzles that will take 200ms to solve, then now the attacker has to do twice as much work as you, to DOS you.  Thus, this does not prevent DOS, but it makes it harder and requires the attacker to invest more resources -- which may reduce the risk somewhat.

Here's a very simple example of how to construct a puzzle.  The description of the puzzle is a random 128-bit number R (chosen by the server, and sent to the client).  The goal is to find a number n such that SHA256(R, n) is zero in its low 20 bits.  The client can loop over values of n (test whether n=0 is a solution, test whether n=1 is a solution, test whether n=2 is a solution, ...) until the client finds a solution.  On average, you should expect this to take about 220 trials.  If the client can perform about ten million hashes per second, then 220 trials should take about one-tenth of a second (100ms).  Once the client finds a solution, the client can send n to the server.  Note that the server can quickly verify that n is a valid solution to the puzzle (it takes only one hash, not a million hashes).  This creates the required assymetry, where the server can very quickly generate new puzzles and verify claimed puzzle solutions, but where it takes longer to solve the puzzle, and where the server can control how long puzzle-solving takes with a fair degree of accuracy.  This is just one example of a puzzle construction; there has been a great deal of research on this problem, and there are better constructions.

You might be especially interested in kaPoW, which implements this idea for the web context.

The main limitation is that this is not going to be secure against dedicated attack.  A serious attacker can just acquire a botnet of a few hundred machines (this is not that expensive) and DOS you, and now you're completely hosed.  Client puzzles can't stop that kind of attack: they can only stop a relatively low-grade attack.  However, stopping DOS is in general very difficult.

A secondary limitation has to do with the broad variability of computational power of clients that might access your website.  A puzzle that a high-end desktop can solve in 100ms might take a mobile device 1000ms to solve (I'm making up numbers here).  If you choose parameters that make the puzzle relatively easy to solve on the lowest-power device that is ever likely to access your website, then you may find that security against high-end desktops is degraded.  Also, it seems plausible that a C program (run by an attacker) might be able to solve the puzzle much faster than the Javascript (run by legitimate users), which would further exacerbate the gap between how fast an attacker can solve puzzles vs. how fast the slowest legitimate client can solve them.  This gap degrades security.

A tertiary limitation is that client puzzles require the client to use Javascript, to log in.  However this might be acceptable.

A variant of this idea is for the server to monitor itself and check whether it is under heavy load.  Under normal conditions, skip the puzzle.  However, if the server seems to be under DOS attack, then start requiring login attempts to come with a puzzle solution.  This mitigates some of the disadvantages of the client puzzle approach, but still is far from perfect, and still cannot withstand a serious DOS attack.

I describe this potential solution, in case you interested, but I don't really recommend it for most sites.  For most sites, the risk of DOS is relatively low, and if it does occur, you can deal with it at the time.  For that reason, my guess is that it probably isn't worth your time or energy to implement these kinds of defenses.  If you've got that much extra time and energy to spare, you might be better off spending it building new features or making your site better.


SQL inject MariaDB with SQLMAP I'm fairly new to sqlmap but I have tried a lot of attacks and have been successful except for this one attack that I have tried. SQLMAP won't detect this nor try to inject an error like this.

So how ik that the site is vulnerable well.
I used http-headers and edited a value which was:

Client-IP: 1'"

Now I tried all attacks on the site it was amazingly protected and not vulnerable to any attacks but then I noticed changing the client-IP to 1'" gave an error:

You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '"'' at line 1

However I tried almost all commands and I'm not really sure why sqlmap won't detect even a little bit of anything.

Can anyone help me out with like a command or something or explain why the site is not injectable.

SQLMap is a great tool if used in correct manner. we need to specify the correct injection point in the complete query of SQLMap
like for example in case of get method used in html form

sqlmap.py -u "www.example.com/file.php?id=1" --dbs //here injection is already specified.

but if its a post method we need to change our query

sqlmap.py -u "www.example.com/file.php" --method="POST" --data"email=ex@ex.com&pass=pass" -p pass --dbs

here pass is the injectable parameter and it will run all its test on this parameter

sometimes header injection exists like for example when the php code takes the ip of the user and doesn't sanitise it

sqlmap -u "http://www.example.com/file.php?id=1" --headers=”X-Forwarded-For: *” --dbs

now the sqlmap will run its test on the headers also i.e X-forwarded-for

SQLMap doesnt perform injections on the headers directly unless its specified.
I think this might answer your query


Passwords in plaintext? I'm doing some research on the App of my telephone operator. I started Burp Suite on my Mac in proxy mode, then I opened up the App on my iPhone and started to sniff some traffic.

I pressed the "login" button and this happened:

My username and my password are there, in plaintext.
The connection is actually HTTPS, but if it's HTTPS, why can I read my username and password as plaintext parameters in the POST request?

Is this normal?

I also tried to replicate the login process with a curl command, and it works only if I use the -k parameter that skip the SSL certificate validation.

What's going on here?

Burp Suite in proxy mode is able to decrypt HTTPS traffic of any systems which trust it. It does this by generating an own certificate and use this cert to register itself as a certificate authority on the system it is installed on. When it then proxies a request to a HTTPS webserver, it does the HTTPS handshake itself, decrypts the traffic, issues a certificate for the webserver signed by itself as a certificate authority, uses that certificate to re-encrypt the traffic and send both the forged certificate and the re-encrypted data to the client.

This allows Burp Suite to eavesdrop on HTTPS traffic. A user which uses a normal proxy server or doesn't trust the Burp Suite pseudo-CA would not have their credentials compromised.


I'm seeing strange names in my list of docker containers, is someone having fun at docker or is that from hackers? I'm trying to run a docker and it fails for various reasons. As I check my list of dockers (docker ps -a), I see those names:

pedantic_gauss
recursing_feynman
adoring_brattain
suspicious_tesla
gallant_gates
competent_gates
elated_davinci
ecstatic_mahavira
focused_mirzakhani

I use docker-compose and I'm sure we do not have such names in our setup files. Is that just something docker people thought would be fun to do?! I searched on some of those names and could not really find anything useful, although it looks like these appear on many sites, somewhat sporadically.

As mentioned in comments this is part of Docker's innate functionality, and is designed to make it easier to work with containers.

The canonical identifier for a Docker container is a SHA-256 hash, which is not the most user friendly thing to type.

So if you don't specify a name (using --name) when you start a container Docker will assign one to you.

The names are a combination of an adjective and a scientist's name, and the source code for generation is here.  There is only one combination that is blocked in the Docker source code which is "boring_wozniak" because Steve Wozniak's not boring.


How should I distribute my public key? I've just started to use GPG and created a public key. It is kind of pointless if no-one knows about it. How should I distribute it? Should I post it on my profile on Facebook and LinkedIn? How about my blog? What are the risks?

Best way to distribute your key is by using one of the key servers that are available, such as keyserver.ubuntu.com, pgp.mit.edu or keyserver.pgp.com.

If you use Seahorse (default key manager under Ubuntu), it automatically syncs your keys to one of these servers. Users can then look up your key using your email address or keyid.

If you wanted to post your public key on LinkedIn or your blog, you can either upload the key to your server or just link to the page for your key on one of the keyservers above. Personally, I would upload it to one of the keyservers and link to it, as it is easier to keep it up-to-date in one place, instead of having the file in loads of different locations. You could also share your keyid with people, and they can then receive your key using gpg --recv-keys.

If you wanted to post your public key on Facebook, there is a field to place it under the Contact Info section of your profile. You can also change your Facebook security settings to use this same public key to encrypt their emails to you.

For example, here's my public key.

To my knowledge, there are no risks associated with publishing your public key.


How to hide local network traffic on my computer? I want to hide any traffic an application makes on the local network, make it look like the network is completely quiet to the system and other monitoring software.

Is this doable? How would I achieve this?

You would need a kernel level driver that could subvert the network stack.  Practically, it's going to be pretty difficult to do.  It would effectively require a rootkit since generally the IP stack on your computer (part of the OS) handles all traffic on behalf of apps and you would have to bypass this.


How does the Yahoo webmail exploit work? I got an email (referring to me by name) from somebody I knew a while ago and the email itself was just two/three lines containing a bit-ly link. Although it seemed like it actually could be legitimate I didn't click the link but copied and pasted it into my browser in a new tab. It took me to a fake MSNBC site with a stupid article without getting any warnings from my Kaspersky suite. So I deleted the email.

Then eight hours later, I see that similar emails were sent from my email account to everyone on my contact list. These email were actually in my sent folder and people had replied back.

I don't think my (yahoo) account was actually hijacked because I could still log-in and of course ASAP I upped all security options and changed to a much harder password. Now several day later, I haven't seen any other suspicious activity on my account. Everything seems normal again.

My questions is how did this work? Was the fake MSNBC page doing something like running a script? But then how did it get into my yahoo contact list and read off all of the addresses and first names and composed emails and sent them out?

EDIT #1: And just to add, I also checked recent activity log at yahoo, as soon as I discovered the attack and the times and places it showed are all consistent with my usage, like I was logged in at the time and it shows my physical location too. I have an antivirus/firewall  solution which is continuously updated. I have a wireless router with fairly strong security settings on it (not using the defaults or anything), with (medium strength) wireless password, MAC filtering and WPA-WPA2 encryption.

EDIT #2: Here is the bitly link http://bit.ly/VVqekC.

Update: The bitly-link was disabled. The website, which hosted the CSRF exploit on Yahoo Webmail, was shut down.

Edit #3: Thanks for the answers everyone. Makes sense. But I still have two questions. Is there any further danger because of this specific attack? Could any information been compromised like any of my emails in my inbox or sent folder or my old password? I did change my password and cleared everything from history/cookies/cache as soon as I found out. In addition, I have the free version which won't let you forward all incoming emails but could something like that have been setup? Second, what was the point of this attack? To what end was it? Just to make me (and everyone else I know) read an innocuous article?

The fake MSNBC page probably contained a Cross-Site Request Forgery (CSRF) attack on the Yahoo webmail.

These attacks exploit web application functions that don't check for user's identity in a proper way, but blindly trust the session cookies. Therefore, if you were logged into Yahoo mail at the time of the attack, the web application had no way of telling whether your requests were legitimate or not, as your browser automatically sends the proper cookies to Yahoo.

You are not noticing anything strange with Yahoo's activity logs because the browser who actually sent those e-mails is yours and the attacker never gained full control of your account (but just of the vulnerable features).

  I have an antivirus/firewall solution which is continuously updated. I have a wireless router with fairly strong security settings on it (not using the defaults or anything), with (medium strength) wireless password, MAC filtering and WPA-WPA2 encryption.

While these security solutions are all fine, they won't protect you from CSRF (or similar web-based attacks). The best defense mechanism in this case is using a script-blocker addon (e.g. NoScript) and only allow trusted domains to execute code.

My final suggestion is to always logout of critical web applications (e.g. home banking) after the use in order to minimize the chances of getting CSRFed and to report the malicious link to Yahoo, hoping they will fix the vulnerabilities.


Amazon S3 policies: CORS or Service Accounts? I have a question about accessing buckets on AWS S3. Let's suppose we have a bucket that has to have public read access by everyone and only my API has to be able to PUT and DELETE items from bucket. To
restrict the access, take a look at these two alternatives:

1) Let public policy configured to allow PUT, DELETE, GET methods and
restrict the DELETE and PUT operations to be executed only by my API domain using CORS.

2) Set the public policy to readonly and create a Service Account to my API with PUT and DELETE permissions in the bucket.

What's the best alternative in terms of security?

This depends on where your API is calling from. AWS (not surprisingly) has many more options if you operate entirely within their platform. If you're operating outside of AWS, I'd recommend option 2. If you're operating within AWS, Option 4 Presented below is the simplest that I think meets your needs, and option 3 is presented in case of stronger paranoia.
1) CORS
Answering abstractly, relying on CORS should be fine, but make sure you are comfortable with writing CORS rules, as a lot of CORS bypass attacks occur due to improper configuration. This would make me a bit itchy, because a lot of faith has to be put into the CORS policy being well written and covering all possibilities. And it's a single-layer of defense, which I've learned to distrust. You could strengthen this, by limit the PUT/DELETE calls in the S3 Bucket Policy to only be allowed from a specific caller IP address if your API calls from a public IP address that you own (note, however, that you won't be able to put/delete objects in the AWS console either unless your web browser is using that public IP address).
2) Service Account
Using a service account would be a better option in my opinion. Not necessarily because it's a technically superior control, but because it's easier to configure and harder to mess up. The vast majority of attacks that happen these days are not because the technology is lacking, but because of poor configuration. Simpler security solutions tend to be more successful for this reason. However, this requires that you protect those Service Account credentials (I'm assuming you're thinking of using an AWS IAM user and giving the API keys to your application), which usually involves regular rotation of the keys, storage in an external encrypted store (such as Hasicorp's Vault).
3) EC2 with a Role
If your API/application is running on/calling from an EC2 instance on AWS, I'd suggest another option. You can give the instance a IAM Role with the write permissions you need. Then you can use the S3 bucket policy to allow s3:getobject publicly, and s3:deleteObject/s3:putObject to only the role you define. Then you don't have to worry about storing/managing API keys. You can add another layer by limiting the put/delete operations to those that come from a specific VPC endpoint, and put an VPC endpoint in your VPC. This would limit the put/delete operations to only come from the specific role, and only come from within the AWS VPC that you specify. Again, please note that this will preclude and write operations to your bucket objects from the AWS Console.
4) AWS API
If you are willing to accept a bit more attack surface in exchange for great simplification of the solution (which may in turn make the solution more likely to succeed), you could use an S3 Bucket Policy to allow public read access from anywhere and all other operations only allowed from your AWS account. Then you can run your API on an EC2 instance with a role granting S3 access. The delineation here is that anything with AWS API access to your s3 bucket can write to it (so your application on EC2, your browser when you're interacting with the console, any other integrations that you add using AWS Roles or API keys).


gpg-agent keeps saving pin for a smartcard I've found today, that enigmail is decrypting a message without asking me for the smart card's PIN. It is asking only once, and then not ask at all.

this is my gpg-agent.conf:

default-cache-ttl 0
max-cache-ttl 0
no-allow-external-cache
ignore-cache-for-signing

scdaemon.conf:

card-timeout 0
deny-admin

gpg.conf is empty

gpg (GnuPG) 2.1.16

libgcrypt 1.7.3-beta

Gnome keyring is stopped. What am I missing here?

I've been looking into this myself. I want to be prompted to enter my PIN every time I request my smart card (Yubikey in my case) to do a sign/encrypt/auth operation. It is possible to enable this behaviour for signing by enabling forcesig through gpg2 --card-edit (see GnuPG documentation):

forcesig   toggle the signature force PIN flag

but not for encryption and authentication operations.

This post on the GnuPG mailing list by Werner Koch himself seems to imply that the smart card itself is caching the PIN.

I will look into this further (perhaps send an email to the GnuPG mailing list) and update this answer if I find any more information.


What are the risks of exposing the Docker for Windows daemon on localhost? A developer running Docker for Windows needs to enable the option "Expose daemon on tcp://localhost:2375 without TLS" in Docker setting > General tab.

There is a warning:

  Exposing daemon on TCP without TLS helps legacy clients connect to the daemon. It also makes yourself vulnerable to remote code execution attacks. Use with caution.

My questions are:

What are the risks of enabling docker daemon on localhost?
Is there some mitigations?

If you expose the Docker daemon without authentication (which is what that options does) then anyone who can make HTTP requests to localhost:2375 will be able to execute Docker commands on your host (the Docker daemon is a REST API so takes HTTP commands)

The consequences of that could be bad depending on the setup in question.  For example an attacker could start a container which would connect back to a system controlled by them and allow access to your internal network.

An attacker could also start a container which maps in directories from the underlying host into the container that they control.

How probable these scenarios are, depends on your exact threat model, but that's the kind of thing that could occur.

As to mitigations, you can configure the Docker Daemon to use client certificate authentication via a TLS cert, some more information about setting that up here

Of course that might not work for whatever tooling your developer needs to use.

An alternative options (assuming that it's Linux containers under development rather than windows containers) is that you could use Visual Studio Code's ability to develop against a remote docker instance (more info here )


Using browser AJAX to initiate credit card transaction with processor? Let's say that I have a website where people can make purchases, donations, etc.

The entire website is served with https.

I store the information regarding the purchases (item, quantity, price) as well as the user (name, address, email) in my database. The last page, where the user enters credit card information, sends an AJAX call to retrieve the data for this purchase as well as my API keys.  When this returns, I send it together with the credit card information that the user entered on this page via AJAX to the payment processor (for instance Authorize.net).

The credit card information would never hit my server.

Would this be secure?  It doesn't seem to me, but I can't pinpoint an attack vector.

Never trust the client browser.

There are four main attack vectors I can see based on this model.

1) Leaked credentials

First, as @JuliePelletier commented, in order for this to work, all the information necessary to make a "charge this card" call to Authorize.Net has to be available to the customer's webbrowser.  This includes whatever secure credentials you have to identify you to the processor.  With those in hand, anyone can make the same AJAX post to Authorize.Net to charge any card or, worse, refund from your account to any card.

2) Altered order data

Second, as @Jay commented, this scheme requires all the information about the order to pass through the user's browser before getting to your processor.  It's trivial for the user to put a breakpoint in the javascript between the return of "get order data" and the call to "send payment data" and alter the variables that are about to be sent. (All modern browsers support this with their built-in developer tools.)  This lets the user order $5000 worth of stuff, then successfully charge their card for $0.01.  Unless you explicitly checked the amount approved, you'd just see that the payment was successful and be out $4999.99.  Even if you added an approved amount check, you'd still have to void off the transaction (which might incur extra fees), cancel the order in your system, and somehow communicate that to the user.

Also, even with a tamper-check, the algorithm for doing that is going to be part of the official Authorize.Net documentation.  Unless it involves a secret key which you do not make available to the Javascript (see point 1), it would be very possible to just recalculate the check after making changes.  And if the tamper-check is supposed to also validate that the card data is unchanged, there's no way to do that without making it available to the Javascript.

3) Spoofed response

Related to the approved amount check from point 2, your AJAX call is going to be expecting some kind of "Approved" response from Authorize.Net before updating the order in your system to indicate that it was paid.  Nothing prevents the user from skipping the call to the processor and faking that response altogether.  Then you think you've been paid, but now you have no record of it - not even a failed attempt.

4) Hijacked calls

Finally, none of this provides any protection against a malicious browser plugin hijacking the user's data.  You can't prevent one from scraping the card data as the user enters it and just sending it off to a server in Russia (or wherever), but you have no protection against one which intercepts the AJAX POST, redirects the whole thing to that server (including your credentials and the card data), and then either passes it on to Authorize.Net itself or simulates a failure so that the user tries again.

It's via a different attack vector, but this article discusses a recent breach which had a similar effect.  In that case, the server was serving a maliciously altered script which caused the card data to first be POSTed to the server, and then sent off to the processor.

  From the consumer's point of view the data entered into the iFrame vanishes and the customer is left with an empty iFrame to complete again. It is expected the customer would assume something went wrong with the web page and re-enter and submit their payment details which, on the second attempt, are submitted direct to the Payment Service Provider.

Your site would have similar behavior - the malicious script would POST elsewhere, return what appeared to be an Authorize.Net "please try again" error, and then remove itself.  The unsuspecting user would then resubmit, and it would go through, with no indication to you or them that anything untoward happened.

The secure method

The secure way to address all these issues (except for part of 4) is to instead have the user POST their card data to your server.  Then, your server sends the request off to Authorize.Net and handles the response.  This addresses all the points as follows:

By sending the request to your processor from the backend, your credentials are never exposed to the user.  This also includes any secret data needed for the tamper-check in 2.
By pulling the data direct from your database to send, you can be sure that it's exactly what you want to be sending, with no chance for the client to modify it.
Because you're calling Authorize.Net in a way the end user can't see or intercept, you don't have to worry about fake responses being returned.
POSTing to your own server still doesn't prevent malicious plugins from scraping the user's data as they enter it, and there's really nothing at all you can do about that.  Additionally, you still don't have any good way to prevent said malicious plugin from altering your page to POST to some random other server on the internet.  But you can verify the IP address posting the data to your server is the same as created the order in the first place, and you can use anti-forgery/anti-XSS tokens to prevent other servers from trying to POST to you.

All that said YOU ARE NOW UNDER HIGHER PCI SCOPE, because you're sending card data to your server.  Here's the summary, but you're basically moving yourself from A-EP (Direct POST) to D-Merchant.  Even if you just immediately pass the card data along and never store it, you're still in that scope - it just means that you'll have an easier time passing your certification.

An alternative

The other secure way which keeps you out of scope is to outsource the entire payment screen to another site (such as Paypal).  This will actually reduce your PCI level, since you have even less interaction with the card data, and it outsources dealing with all these security issues as well.


How does Bitlocker Drive encryption work and which info are sent? I'm looking forward to discovering more about the way in which USB devices encrypted with BitLocker are protected.
If I insert a USB key encrypted with BitLocker on a different device, I can access the storage only if I have the recovery key, right?
If the USB key has been encrypted with BitLocker in a device for which the user is not admin, can the admin find out when it is inserted into a different PC?

If I insert a USB key encrypted with BitLocker on a different device, I can access the storage only if I have the recovery key, right?

That depends entirely on what key protectors are used on the flashdrive. A key protector is a bit of BitLocker metadata that provides a way to obtain the actual disk encryption key. Common key protectors are the recovery key, passwords (or PINs), a key file stored on another flashdrive, or (for boot volumes) a TPM.
If a flashdrive is encrypted on a system that already uses BitLocker, and is set to automatically unlock on that system, a key protector is used where the host machine will store a secret on its (encrypted) drive. If that's the only key protector other than the recovery key (which is always created by default, although it can be removed), then the only way to unlock the flashdrive on another computer is to use the recovery key, yes. However, it's pretty common for an encrypted flashdrive to also have a password key protector; in that case, you can decrypt the drive on any machine so long as you know the password, which is much more memorable than the recovery key (it's also more at risk of brute-forcing, so BitLocker will attempt to delete this key protector after multiple failed guesses... though that only works if the real BitLocker driver is running, and is able to write to the flashdrive).
Note also that the usual way to encrypt a flashdrive with BitLocker is a bit different from how BitLocker normally works. Since it's expected that a flashdrive might need to be used on machines that don't support BitLocker, the drive's main partition is shrunk slightly and a second partition is created. This second partition gets a small Windows executable that can read (though not write) BitLocker-encrypted partitions (such as the main partition of the flashdrive). For the main partition, I'm not sure if it works like a normal BitLocker volume (which contains some behavior that seems specific to NTFS) or if it works a bit differently, in some way potentially agnostic to the underlying FS.

If the USB key has been encrypted with BitLocker in a device for which the user is not admin, can the admin find out when it is inserted into a different PC?

No. Cryptography doesn't involve any sort of "phoning home" - it's just math - and there's no mechanism for BitLocker to even store a routable address to the machine where it was encrypted. Windows can, depending on configuration, automatically upload the recovery key when a drive is encrypted (either to Microsoft or to a domain controller), but as far as I know it won't automatically search for any such uploaded key - the location or even fact of the upload isn't part of the protector, so it wouldn't know where to search - and of course if the recovery key wasn't uploaded at all (or was only uploaded to a private network that the different PC isn't on, such as the controller of a corporate domain) then there wouldn't be anything to find (and thus no way to link the drive to its encrypter) anyhow.


Help understanding malware infection I'm kind of a newbie to security and need help fully understanding how I would infect myself inadvertently.

Let's say I was to download a .zip file attached to an email and I unzipped the contents. It's my understanding that the only way my computer would be compromised would be IF I EXECUTED any of those files contained within...right? Just simply having them on my hard drive does nothing...right?

Generally speaking, you are correct. Let's look at some exceptions:

If the malware exploits a vulnerability in your email program.
If the malware exploits a vulnerability in the software used to "unzip" it.
If the malware exploits a vulnerability in the software used to view its contents (ie Windows Explorer).
If the malware exploits a vulnerability in the program used to open an extracted.
If the files are used by other software, for which an exploit exists. I say this because you specified "executed" not "opened".
If the software is inadvertently ran by something else. For example, a DLL could be loaded and ran by some other software.


VMware VM run on insecure OS I run VMware with Linux through my Windows OS. I want to use the Linux VM for online transactions. Is it possible for a virus, spy or worm to attack my Linux VM from the Windows host? Is my Linux environment the same secure clean Linux installation?

Is it possible for a virus/worm to attack on your host to attack the guest OS?  Yes.  Is it likely?  No.

Malware can do anything you can do, including writing to the virtual disk.  The easiest route would be to simply mount the virtual machine drive, and write new malware to it. This is unlikely because it would take specially crafted code to exploit this.  It's unlikely that malware writers would care about this rare corner case.  Malware is about volume, not targeting individuals.  Unless someone is specifically after you, it's not a serious concern.

What is very easy is running a keylogger on the host OS.  A keylogger on the host OS would still be able to log keystrokes on the guest, since all keystrokes still go through the host OS and the guest OS is just another application running on the host.

So a virtual machine can't protect you in any way from keyloggers.


Python desktop application: storing cloud database passwords I am currently building a Python desktop application in PyQt/PySide which will be compiled to .exe. I am planning to use the Azure SQL database and a remote file storage (like S3).
An issue arises that the application needs passwords (credentials) to access these services and be able to upload files etc. "Hardcoding" them is obviously a wrong solution:

the application could be possibly decompiled or the passwords could otherwise be accessed.
the application would lose access to the services if the passwords ever changed. I will mostly know the users but I am not planning to restrict resale or installation, nor an automatic update mechanism, which means I will be unable to notify all the potential users if I change something.

I have thought of running a server (web service), like in node.js/express, to which the users would authenticate (there will be a login/accounts functionality in the application) and the service itself would be storing the actual credentials server-side, that is, the desktop client application would never have to access them directly, and the users would only be accessing the server through the client application, not the actual database.
However, I wanted as little overhead as possible, only the client + database - user authentication would be done simply through querying the database directly from the application - without a server.
As I understand it, from reading articles and similar questions on the forum, there is no secure solution outside of running the server - is this a correct conclusion? That is, running a server is inevitable?
Thank you in advance for advice.

If it is important to you that your users not be able to obtain the credentials needed to access the cloud services directly, your ONLY option is the indirect access (through a server) that you mentioned.
However, there may be other options, depending on the security model of your application. For example, if each user gets their own storage (not shared between users), you could create some lightweight users (possibly via Azure Active Directory? I'm not an Azure guru. For AWS you'd just use IAM accounts) that can access the cloud services directly, and then lock down (on the cloud platforms) what those users can do (e.g. in the DB, limit the user permissions so they can only run specified stored procedures rather than having free-form access to the DB). This might also work if storage is shared but with some restrictions (like read-only access to others' data). Things like S3 tend to be very free-form, though; if you give somebody an S3 access key, you can't really control what they put in there and you can only control what they take out by limiting the buckets they can access.


Security of several files all using same password/key (7zip, AES256) I'm working on a simple secure mirror for potentially untrusted services like Dropbox, Owncloud and so on. (Current code may be seen here: http://www.codeduce.com/extra/secure_mercurial)

Currently I'm relying on 7zip for encrypting the individual files. So, I am encrypting every file with a password and mirror it to the watched directory of the service.

Question: There will be many of those files, all using the same password. Does this lower the security of AES256? I mean is there any possibility getting the key faster, if one has several encrypted samples?

If so, is there a better tool/algorithm for that situation?

How secure?

Your approach sounds good. But, read on.

  If so, is there a better tool/algorithm for that situation?

There always is, but nothing I'm familiar with is significantly better, this tool is likely good enough.

Details of 7zip encryption

There has been previous questions and answers on 7zip encryption:

How key_derivation and key_verification functions are implemented of a 7-zip archive's encryption mechanism?
Is 7-Zip's AES encryption just as secure as TrueCrypt's version?

From these it is easy to conclude the answer to your question: 7zip uses key derivation practices which appear pretty good. Also it uses salt. Therefore, all files will be most likely using different encryption keys.

Possible issues

Most likely the weakest link will be the entropy of password you have chosen, therefore choose the password carefully. A low-entropy password will still be easy to break. For instance, if password is a common dictionary word, it may take attacker only a few minutes to guess it. Please, use good password/passphrase choosing practices.

Do you intend to retain the original files? (I.e. is this a backup?) If yes, you must ensure the unencrypted files are never readable by attackers. If you erase the original files try to make sure files are entirely erased.

Last, but not least, remember that if you are using single password for all files, if attacker is able to guess that one key, they'll be able to decrypt all the files encrypted under that key.

DISCLAIMER: I have not reviewed the source code of 7zip, but answer is based on other sources.


Using Tor from behind a Proxy (like Burp Suite) I am interested in exploring a bit of the darknet, and I was wondering about the feasibility of running a Tor exit node from behind a local proxy like Burp Suite so that I could ID the destination URLs and look for hidden services, this could let me essentially develop the seed list for a "search engine" for the darknet. The only problem I'm having is that although I can route my own browsing through Burp Suite I can't get the traffic from the node running through it. Any ideas?

Edit: Also of interest is the same question for the general internet. I know there was the case where a guy was questioned for doing it. And disclaimer: I don't want to actually steal people's info or release it, more of a curiosity.

Have a look at this: http://www.ojscurity.com/2015/02/docker-zed-attack-proxy-with-tor.html

Not tried it myself, but it looks like it could be what you want :)


Is Linux's 'W' command a security breach? I was surprised that the out of the box 'W' command on Linux provides so much information without needing any SUDO or admin permissions. In particular, the command shows the command line of each user's current process. This seems to be a huge hole as it could potentially show someone accessing a hidden file (for instance, the command 'vim .ProofThatTheMoonLandingWasFaked.txt'), plain text passwords (yes, I know that should never be an issue since plaintext passwords should never be entered but it still comes up), etc.

Does the out of the box 'W' command constitute a security hole in a system?

w, by itself, isn't what lets you do this; it doesn't have any sort of elevated privileges, and everything it can do is something you could already do yourself. The actual thing that lets you see other users' processes is that process info is stored in the /proc/ directory, and all users have access to the /proc/[pid] directories that store individual process info.

If the question is instead "isn't /proc being world-readable a security hole," the answer is "a security hole according to what threat model?" Security holes are when someone can do something that they shouldn't be able to do. Many Unix-based systems (this behavior predates Linux) don't consider things like command line options and who's running each process to be sensitive information; making this world-readable was an intentional decision that it was not something that needed to be restricted. This behavior might be good or bad depending on your needs, but the point is that unless it's a problem on your system it's by definition not a security hole.

If you often enter passwords on a command line (that presumably you don't want other users to see), or if you don't want users to see what other users are doing, then this is a security issue, because then it lets people do something they shouldn't be able to do. On Linux, being Linux, you can modify this behavior and restrict /proc. If, like the designers of most of these systems, you don't see an issue with people seeing what programs others are executing, then this isn't a hole. Traditionally, that's not an issue, so most systems allow this access.

(For hidden files: They aren't actually a security feature at all; the reason they exist is convenience. Anyone who can list files in a directory can list all files, including hidden ones).


Spoof IP address after a TCP handshake I know it is not possible to perform a successful TCP Handshake with a spoofed IP-Address.

However I wonder:
Is it possible to spoof the IP once a TCP handshake was performed successfully?

For example:

Perform the handshake
Use the session (with a different IP) and send a request
The response is delivered to the spoofed IP

Thanks in advance!

Is it possible to spoof the IP once a TCP handshake was performed successfully?

No.

A TCP session is defined by four items:

Source IP address
Source IP port
Destination IP address
Destination port

This comes from RFC 793:

  To provide for unique addresses within each TCP, we concatenate an internet address identifying the TCP with a port identifier to create a socket which will be unique throughout all networks connected together.

  A connection is fully specified by the pair of sockets at the ends.

If you were to:

  2) Use the session (with a different IP) and send a request

When you change any one of those four parameters, like the source IP, the new packet is no longer a part of that TCP session, and will not be "delivered" because it does not match the session definition.  Instead, it'll be an out-of-state packet, and dropped or rejected.


Securing Time Sensitive Data I have a number of time sensitive, embargoed pieces of information that I need to distribute over the Internet and have received at a precise time. I'm currently dealing with the problem by uploading to a shared Box.com folder at the time we wish to release, but since the data is large (100-200mb) and the receivers have varying levels of Internet access (from none to 1gbps+), this means that some people receive it hours later than our embargo time.

I have considered uploading the info early, but encrypted and emailing out the key at the last minute, but since not everyone has always-on Internet, that doesn't quite solve the problem (and getting to Internet access isn't always possible). Similarly, the volume of people receiving precludes a teleconference or similar where the password is given out (not to mention that sometime the data needs to be released at midnight).

Is there a method I can use to set up an encrypted archive on a time-release? Complicating matters; is there a method I can use that is relatively straightforward for non-technical users to set up on their own machines?

I'm wondering if there's a way to do this easily and relatively cheaply with trusted hardware, such as RSA tokens we can distribute, but not being able to necessarily trust the machines is a sticking point.

I only need granularity down to about the half-hour - this isn't financal market moving stuff.

Unfortunately (for you), computers are deterministic systems. What a computer can compute, it can compute -- and it can do so at a speed which depends quite heavily on the computer model. This means that you cannot enforce an exact timing without external events: without extra input, a computer is an isolated system and can reach any computable conclusion from the available data at a speed which will depend, roughly, on its price.

So you need a reliable clock somewhere in your system. When you envision publishing a decryption password, then you are the clock. Using encryption is a good idea since encryption concentrates secrets: instead of having to deal with 100 megabytes of data, you just have to publish a small size value (the decryption key), which can be small enough to be typed manually by a human or even uttered over a phone call.

At that point, you have a choice, which is where the clock is:

The clock could be in the physical hands of each customer. This calls for a tamper-resistant device which can store a key, includes a clock, and can perform some computations over both. This page pretends that the "VaultIC" line of USB tokens includes a real-time clock and can implement the TOTP generator for time-based passwords, so it has the needed potential. Some specific on-board programming would still be needed, though, to match your needs.
The clock is not in the physical hands of each customer. Instead, they must contact someone (e.g. you) (or be contacted) at the publication time. There are various ways to convey information in our modern world: Internet-based (Web, emails...), phone calls, SMS, radio... The idea here is that if customers cannot be expected to always have Internet access at the right time, they must have a link with the external world. If one of your customers is a Buddhist monk who lives as an hermit in a cave on the flank of an Himalayan mountain and goes to the nearest village only once a month, then that customer will be hard to reach; but, similarly, it does not matter much that he gets the embargoed information immediately since he does not have any contact with anybody -- such information is useless to him until his next contact with civilization.

Publishing the decryption password on your Web site and sending it by email to the customers and sending it by SMS to the customers, ought to be sufficient. Customers who cannot be reached by any of these means are decidedly away from the connected World, and therefore can wait.


How bot(s) have guessed my wordpress login page? I have a wordpress site (fully patched) that used to receive many attempts to log in based on dictionary attacks. I changed my admin user to something uncommon and use a really strong password.

Apart of that I changed my login page using rename wp-login.php plugin. I changed my login url to something like http://foo.com/blog/?pencil. For years the bots failed to guess my login page (still having many 404s).

For the second time in a month. First time I had a failed attempt and changed url to http://foo.com/blog/?paper and didn't think much about it. Second time happened today. Exact events:

19th April

Successful login from my employer office (via proxy) to http://foo.com/blog/?pencil at 18:00 from my company laptop.
2 failed attempts from 70.32.73.128 (report about the IP ), a IP from California, at 02:54am GMT (The server seems to be reported as hacked) using admin username (that btw doesn't exist in my wordpress)
I changed password and url to http://foo.com/blog/?paper
I enabled capturing of incoming passwords in log.

Now

Yesterday (11:10 am) I accessed to blog to correct an entry from my employer network (same proxy).
Today at 11:55 1 failed attempt from 213.248.63.27 (Virus Total report about the IP), a russian IP with suspicious sites like vrn.sauna.ru (probably NSFW url). It used oscarfoley as username with no password (my username is not oscarfoley or similar)

I feel pretty secure as the bot has to guess the login page, the admin user and the pass. However, by reading this site I am a little bit paranoid.
So my main question is:

How the bot has "guessed" the paper or pencil login page?

Could be my employer proxy/network be compromised? (Like a hacker having access to proxy logs...)
Could it be a broad dictionary attack (something like a boot scanning all wordpress servers in the internet to see if the login page is pencil)?.. or a exploit in wordpress?
Is there anything more I should do to protect myself?
Could it be a personal attack using public information on internet? Or a bot that uses public information for broad attacks?
Why the empty password?
How can I be sure I am not hacked? (Forget about this as it is pretty good answered in this question)
Could be my laptop or my pc at home be hacked and got the url from it? My guess is no because otherwise they would have my password...

EDIT: To be more clear, attacker hit the login url directly with NO failed attempts on other similar urls. Check here last 404 errors:

Many web scanning tools (e.g. Wikto) have the capabilities of launching bruteforce guesses against a URL. There is nothing stopping an attacker from using a dictionary and say curl or wget to bruteforce either:

while read line
 do
   wget -qO - http://yoursite.com/$line
 done < /usr/share/dictionary/wordlist

A common task I would do for pentesting, would be something similar to the above, where I would wget a copy of the site, parse out each word, put each word on a newline, then search the site for directories of any word listed on their site. This also came in handy for username a few times.

Now you mention wordpress, and it should be stated that when you use plugins, some of those plugins can contain "pingbacks" or "hey I also use this plugin" where your site would be listed. This could be another vector where an attacker saw your site elsewhere, and targeted it. As for WP in general, sites like "Scritch" can tell someone what is running on the site (CMS), what plugins are in use, etc. So imagine the following: Attacker sees your site on say a pingback, takes the site name, shoves it into scritch. Determines they will attack you. They don't find the login page, so they use a similar tactic (shell script) to find something.

I would worry little about attackers, and focus on creating say a mod_rewrite rule or htaccess file similar to the following:

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_URI} ^(.*)?oscarfoley\.php(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^(.*)?wp-admin-login$
RewriteCond %{REMOTE_ADDR} !^1\.2\.3\.4$
RewriteCond %{REMOTE_ADDR} !^5\.6\.7\.8$
RewriteRule ^(.*)$ - [R=403,L]
</IfModule>

Where 1.2.3.4 is your home addr, and 5.6.7.8 is perhaps your company page and be done with the worries of someone trying to bruteforce their way in via login page. Another alternative which is security through obscurity would be to create a URL based on say a SHA1 checksum of a word, versus a word. E.g.

$ echo 0sc@r | shasum5.16 -a 1
2ee681adc62a5ca2865bb7424b6a97a9050ddcd4  -

Where 2ee681adc62a5ca2865bb7424b6a97a9050ddcd4 becomes your login URL. Again, security through obscurity, but the notion here is that is someone were to guess that URL at some point, you can deduce that your traffic was somehow sniffed, or cached somewhere.

ADDED DUE TO OP EDIT

The 404s from one address mean little to some degree. You have no idea if that address connecting is working in connection with another address doing bruteforce attempts. (e.g. distributed scanning/sharing)


How to select the right SSL cipher suite for low powered hardware? Scenario

I have many set top boxes that feel sluggish when accessing HTTPS websites. I would like to find out which SSL cipher suites are most appropriate to use for our websites, so that the boxes perform optimally.

Unfortunately the OpenSSL command line tool is not available on it so I cannot benchmark it that way.

In such an environment, how do I go about picking the best cipher suite to use?

Generically speaking, performance ought to be measured in a realistic situation, so you should use as client one of these sluggish set top boxes. When you connect to your server, run a network monitor tool on the server (e.g. Wireshark) to get the precise timings of exchanged packets; this will show what cipher suites the client supports (they are listed in the ClientHello message), what the server decides to use (in the ServerHello message), and pinpoint the operations where time is spent.

Performance issues with SSL will occur either during the handshake, or afterwards when actually sending and receiving data.

For the handshake, you may get issues with latency because a SSL handshake is four-way (two roundtrips before client begins to send the actual HTTP requests); however, this occurs only at the beginning of the SSL session. Browsers keep connections open.

At the handshake level, you may get some performance issue related to the asymmetric cryptography, although I don't quite believe it because a set top box which can run a modern Web browser ought to have enough punch to do such cryptography quite efficiently. You may want to make sure that your cipher suite uses a RSA key exchange (i.e. a cipher suite of type "RSA", not "DHE_RSA") because RSA key exchange is very light (computationally) on the client. However, in any case, since connections are kept open and SSL sessions reused, this may matter only for the very first connection from the client to a given server, and should not impact performance in a continuous way.

Another one-time impact is that for the very first handshake, the client must validate the server's certificate, and that can be expensive -- especially if the client must download some intermediate CA certificates, and obtain CRL and/or OCSP responses. You will not be able to change that with a choice of cipher suite. Make sure that your server sends a complete certificate chain to the client.

For continuous sluggishness, the symmetric encryption part would be a more plausible culprit. Roughly said, you want cipher suites which use AES or RC4, not cipher suites which use 3DES. 3DES is known to be slow.


Can an iOS backup be compromised? I originally posted this on the Apple Stack Exchange but it was suggested that it was off topic, so I’m posting it here in hopes that this is a more relevant place for it.
Say that an iOS device has been compromised by some vulnerability. If one were to backup their device to their computer (or iCloud, but it’s my understanding that making an encrypted backup to a computer allows for more to be stored in the backup, such as passwords) and then restore the OS using the backup to restore settings, could the backup re-compromise the device?
Secondly, have there been any documented cases of persistent threats (outside of jailbreaks) that are remotely exploitable and can persist after a restore?

Theoretically, all off this is possible, but in practice it is rare.

could the backup re-compromise the device?

It could but it probably wouldn't since any malware installed on the device generally wouldn't be backed up.
One possible risk would be that if the initial infection occurred through a malicious text/email, and you restore the texts/emails too, then viewing the same text/email might result in reinfection.

have there been any documented cases of persistent threats (outside of jailbreaks) that are remotely exploitable and can persist after a restore?

Yes, for example this proof of concept exploit, which relied on a bug in Broadcom chips, could potentially persist across restores since it overwrote the chip's firmware.


How does Burp update XSS/vulnerability scanning rules/payloads? The first point, that it updates with new release. So if somebody discovered new payload for popular frameworks, it will be in burp only with new release. Does Burp app load payloads from Internet sources?

P.S. Except plugins =)

In their official document "Updates Settings", it states that:”New scans that start after the update will use the updated version of Burp Scanner. It is generally desirable to enable automatic updates of Burp Scanner to ensure that the latest scan checks are available.".  So it means you must update the Burp Scanner with the updated version for the latest scan checks.


How can you draw attention to your web application honeypot? Unsatisfied with existing software, I'm currently toying around with writing a web application honeypot.

My question is: how do you draw the attention of attackers and automated attacking software to your honeypot?

This will greatly depends on the usage you intend for the honeypot.

There was another discussion linking to an interesting document highlighting legal consequences of honeypot usage. Indeed, advertising the honeypot the wrong way might lead you in hot waters from a legal perspective.

Some specific honeypots implementation will therefore not be implemented without the help of a lawyer qualified on IT security questions (and the linked post was closed as out-of-topic because of this very reason: at some points it requires more legal than technical knowledge).

However, taking some precautions and staying transparent on your position might help being out of any legal issue. In the linked post, among other suggestions I made these one are most specifically related to honeypot advertising (I encourage you however to read the whole thread and the original document linked by the OP which was very informative):

  Do not encourage any illegal activity. Do not advertize the honeypot in a dubious way. Either do not advertize it at all, letting
  automated scanners discovering it, or advertize it officially as some
  kind of "hackme" educational system. For instance, spreading pseudo
  "leak" information on the Internet regarding the server to encourage
  attacker to exploit it can lead you to trouble.
  Present the honeypot system as a private monitored system. Honeypots are heavily monitored systems, and there are laws defining
  the data you may or may not collect regarding other people's, how long
  you are allowed to keep them and what processing you may do with them.
  Present the honeypot as much as possible (since some service do not
  have any banner...) as a private system whose usage imply user's
  consent to be monitored. This will limit any potential threat
  regarding this data collection and analysis activity.


Secure keys in hardware I know the device keys for Android are in hardware and created used fuses. Where is this fuse memory? Is it directly accessible to the processor?

Because the hardware key should not read out into the memory, that means the AES operation needs to be done in the processor directly. Where is the AES implementation done that uses this fused key? Is there an equivalent of AES-NI instruction set in arm?

If this is not correct place for this question, where can I ask it?

Hardware secure keys are not a feature of Android, they're a feature of some (but not all) devices running Android, including most if not all high- and mid-end smartphones and tablets. The way they work depends on the capabilities of the hardware.

All processors based on an ARM Cortex-A core (and some older ones), whether 32-bit or 64-bit, have a feature called TrustZone, which is a sort of highly specialized virtualization. There are just two partitions: the secure world and the normal world. The secure world has access to the normal world, the normal world doesn't have access to the secure world. TrustZone itself isn't enough to do anything useful: the memory bus has to enforce the protection, which is the case on most (but not all) system-on-chips (SoC) based on a Cortex-A.

On a suitable processor, the secure world runs a trusted execution environment (TEE) with a small operating system. On reasonably modern Android versions, the keys of the Android keymaster are stored in the TEE, Android (even fully rooted) does not have direct access to them. There are phones where the device encryption key resides inside the TEE, but this isn't always the case.

The TEE data is stored encrypted using a key that Android cannot access. This key is derived from a root key which is stored in write-once memory (this can be fuses or other one-time-programmable (OTP) memory technology). The reason Android cannot access this key is that the processor ensures that it is only accessible to the secure world.

On some SoC, the secure world directly reads the memory. On other SoC, there is a dedicated component in the SoC that has exclusive access to the root key, and all the secure world on the main processor can do is to request a key derivation based on the root key. This doesn't change much regarding the security of the system: in either case, the key that the security of the system relies on is a key that gets stored in secure world memory.

Restricting the secure world to a derived key has one advantage: the key can be changed by changing the tweak on the derivation. An attacker who partially breached the TEE and managed to read data, but not to execute arbitrary code, would have access to the key. If the bug is fixed and the new TEE version uses a different key derivation parameter, then the attacker will no longer be able to read TEE data.

Some ARMv8 processors (including all high end phones today) have instructions similar to AES-NI, but this has no impact on security (except indirectly, in making cryptography less expensive and less prone to side channel attacks). AES-NI and the ARM equivalent are just ways to compute AES faster, the keys and data are still in the same place.


Should 'openssl verify' recognise an exceeded 'Path Length' constraint on a root/intermediate CA? Background
Following the guides here and here I am setting up a multi-level PKI. I have increased the pathlen config to 3, such that I can generate one root certificate that I can use to sign the first intermediate and store securely. The first intermediate will be stored on the configuration workstation and be used to generate second intermediates, which will be used to generate the final certificates actually used for communication within a remote cluster.
/Background
In experimenting around with this I found that if I reduce the pathlen value used to generate the CA, even to 0, then in a command such as this:
openssl verify -CAfile <root ca> -untrusted <chain of intermediates> \
    <cert to verify>

the certificate is still validated as OK.
Since asking a question on this here I also set up a similar trust chain using openssl (1 CA, 2 intermediate CAs, 1 server certificate) and assigned the pathlen "1" to the CA, and pathlen "0" to both intermediates (one intermediate was signed by the other). openssl verify still said this was OK.
I would have expected the Max Path Length of the CA to make the leaf certificates in both cases invalid, is this wrong?
Update: Outcome (hopefully to illustrate the understanding I've gained)
It turns out that when I was verifying the chain I set up via openssl, I was verifying the second subordinate trust certificate, rather than the server (leaf) certificate. When I set up a chain of the two subordinates to pass to the -untrusted flag, and verified the server certificate, openssl (correctly) rejects this as invalid.
This means that the minimum number of trusts for a valid certificate where a pathlen constraint is enforced is 2 - the root (self-signed) CA, where any pathlen value is ignored, and an intermediate certificate (which can have a pathlen value of 0 at minimum). Note that even though the pathlen is 0, a valid certificate can still be signed by this intermediate, as the pathlen constraint only applies to the number of nodes in the certificate's trust chain, not the certificate itself.
The author of the articles I was using as source information on this gets this wrong. Additionally the way cfssl at time of writing is set up to accept a pathlen value for a self-signed CA value only (not for any subordinate CA) makes this even more opaque, and probably caused the confusion on the part of the author.
In retrospect, it makes sense that a pathlen value would not need to be applied to a root CA, as the CA is ultimately trusted (or should be for any signed certificates to be valid). It is on the authority maintaining the root CA key to sign any CSRs requesting CA status or not (including checking the pathlen value), depending on their policy.

The pathlen constraint is only valid in subordinate CA certificates.

If you followed the first article you linked and generated a trust-anchor with a pathlen constraint then it is not checked.

According to RFC5280 section 6.1.4 (k) basicConstraint is only checked in certificate i+1 (where the trust-anchor is the first (i=1) and subsequent certificates in the alogrithm are i=2, i=3 and so on).  That is, don't check it in the trust-anchor, only check it in subordinate CA certificates.


First setup security protocols (key transfer) in not-secure environment This question might very well be more a confirmation than anything else, but I'm breaking my head over a problem I try to solve. I hope someone can either confirm my thoughts or tell me something I'm missing.

We are trying to setup a secure environment on an existing system (I'm aware this is not the way to go, but companies..) and the problem I have is the following:

Tool A is used to update system B, system B does currently not contain any keys for a secure exchange. The update system B is receiving will contain keys to make secure exchange of information and future updates possible. This will be in plain text as system B isn't aware of any secure protocols.

The interface used to transfer the update to system B should be considered not secure, and could have a potential listener.

Would there be any way of securing system B without the key leaking?
So far the only solution I can think of is securing the environment of system B while transferring the software. This limits the possibilities heavily on updating system B, is there another solution?

Summary: We move from a not secure way of updating to a secure way of updating, the problem we face is the first update will contain secure data send on a non-secure way. Is there a way around this?

If you start off with an insecure system you can only secure it first. It seems however that you start off with a secure system for which the communication is not trusted.

Any initial operation you perform can be repeated by an attacker. You can only escape this if you have either a shared secret, a private key for which the public key is trusted, or a trusted public key of the other party already installed.

As this doesn't seem to be the case, the only thing you can do is to mitigate things. You can send an update to the system that implements DH key agreement. Then you let both systems generate a DH key pair and perform the key agreement. The resulting keys derived from the shared secret can then be used to keep messages confidential and authenticated.

The problem with the above approach is that an adversary can perform the same update or provide their own key agreement. Now the fact that anybody can do the update cannot be mitigated. However, you can include the public key used for the key agreement in the update itself. That way there is a (semi-?) trusted public key available for the system, and the resulting secret is known to be correct.

Of course, that will still leave the server guessing if the shared secret is from the previously insecure system or an adversary. You can mitigate this fact by including using a random update ID in the key derivation, and make sure that this ID can only be used once. That way all the security is just dependent on the update, so as long as that's secure - and the key agreement is performed immediately - then you're in the clear. If there is a system ID of the insecure system, use that in the key derivation as well - the more dependencies the harder it becomes for an adversary to mess with the system.

In any next system you design / roll out, always include a public / private key pair into the system and trust the public key in the server. Also include a trusted public key of the server. That way you've got a good way of bootstrapping security once it is required.

Any way you can introduce trust can of course be utilized. For instance, you can send out engineers with their own trusted private keys and use that to initially set up trust for the system. Humans may be better at estimating the initial security of the system after all (if the computer is in the basement of a hacker then it is probably not secure).


sharing private key sTunnel All of the sTunnel guides and implementations at work do the same thing, they say once the private key and the public cert are created on the server, you need to cat them together and then share with the client host.

While this makes perfect sense to me with the public cert (as client will encrypt data using it) surely sharing the private key goes against the whole SSL ethos?

Stunnel is SSL and, in SSL, private keys never need to travel. The "SSL ethos" is that X.509 certificates are used to authenticate peers without a pre-distributed shared secret. For example, when you connect your Web browser to https://example.com, the SSL layer recognizes the server certificate and can make sure that it talks to the real "example.com" without needing prior knowledge about that specific site.

Stunnel is out of this model, since it is typically used between two machines that already know each other. This allows lighter models to be used.

By default, stunnel does not validate certificates. This is stated as so in the HOWTO page (in the "How does stunnel check certificates?" section). If you did not change that setting, then it does not matter at all what certificates you use. Of course, not validating certificates leaves the tunnel vulnerable to Man-in-the-Middle attacks. This can still be acceptable, from a security point of view, if the tunnel is meant to convey only an underlying protocol that already includes cryptographic protection; typically, you use stunnel to get through a school/company firewall, but inside you just run some SSH. The stunnel is there only to keep the firewall unwary of the SSHish nature of the communication. In that specific case, not validating certificates is fine. (Well, fine with regards to your security. You are still circumventing your school/company firewall, which is morally and legally questionable.)

Most stunnel guides explain how to configure stunnel in that no-verification mode, and copying the certificate on both client and server is the most expedient way to keep things running.

If you configure stunnel to validate certificates, then:

The client must be able to check that the server's certificate (the certificate is the public part, NOT the private key), which entails either knowing it beforehand, or verifying its signature with regards to a known CA.
When the client has verified that the server's certificate is genuine, it must still check that it is the certificate of the intended server.
If the server requests a certificate from the client, it must similarly be able to verify it, and check that it corresponds to an allowed client.

There is no code in stunnel that compares the client and server certificates with each other. They really live in distinct worlds; the client certificate is validated on the server, the server certificate is validated on the client. Having the same certificate on both systems has no influence whatsoever on the behaviour of either.

In a certificate-check system, if both the client and server use the same certificate, then the client may impersonate the server, and vice versa. If there are only two machines, then this does not matter much. If there are more machines (e.g. two clients to connect on the same server) then this can matter a lot (you do not necessarily want to allow a client to frame another client with a fake server). And, of course, sharing the private key implies that the private key travelled from one machine to the other, which either used a preexisting tunnel (e.g. SSH), or was a risky operation. Private keys should remain private, and the more a private key travels, the less private it becomes.


Do companies shop for 0-days on black markets to fix them? Is it known for software development companies to shop for 0-day vulnerabilities on black markets in order to burn them?

Microeconomics tell me "no", as some sources claim that 0-days are short in supply, thus really expensive these days due to combined efforts of security companies and such, and as we know from "Fight Club", "If X [cost of failure] is less than the cost of a recall, we don't do one." :)

But I would imagine that there could be somebody who does this for high-profile enterprise customers, or at least for a publicity stunt, and I just didn't happen to find out about it.

If there is such a company, I want to know their story.
If there seems to be none, I'd be happy to state the reasons.

Yes, I know of a few, but companies will not be public in their efforts to search for and purchase 0-days because: 1) if publicly known, it would increase the price, and 2) it creates a greater demand, which means greater incentive for attackers to hunt for 0-days, which increases the risks for the company.

That's why they use Bug Bounty programs instead. It flips the market so that the company benefits more directly without increasing the risks.


How to get GnuPG fingerpints only for specified key name, not for substring matches? I have few GnuPG keys: test, test2, some test. When I invoke
gpg --fingerprint test, fingerprints of all keys are listed. When I run gpg --fingerprint test2, only test2 key fingerprint is printed. How can I list fingerprint only for key named test?

From the GnuPG manual page

  --fingerprint [=names=] List all keys with their fingerprints. This is the same output as --list-keys but with the additional output of a
  line with the fingerprint. May also be combined with --list-sigs or
  --check-sigs. If this command is given twice, the fingerprints of all secondary keys are listed too.

The relevant part of the documentation (man gpg) is the chapter "HOW TO SPECIFY A USER ID", pretty much at the end of the manual page.

The default mode is substring matching, which is what you observe (test2 contains the substring test).

  By substring match.

  This is the default mode but applications may want to explicitly indicate this by putting the asterisk in front.  Match is not case sensitive.

Heine
*Heine

You want to use exact matches instead, where you have the options of matching words, a mail address or the whole user ID string depending on your specific needs:

  By exact match on OpenPGP user ID.

  This is denoted by a leading equal sign. It does not make sense for X.509 certificates.

=Heinrich Heine <heinrichh@uni-duesseldorf.de>

  By exact match on an email address.

  This is indicated by enclosing the email address in the usual way with left and right angles.

<heinrichh@uni-duesseldorf.de>

  By word match.

  All words must match exactly (not case sensitive) but can appear in any order in the user ID or a subjects name.  Words are any
  sequences of letters,  digits,  the  under‐
            score and all characters with bit 7 set.

+Heinrich Heine duesseldorf


How to Detect if my Android Phone Came With Pre-Installed Malware? I noticed my android is attempting to run tasks that I haven't authorized and am not aware of. When I factory reset this device, it attempts to open what I believe is some sort of malware. If there's no internet connection, it just loads a transparent screen. It remains this way until I kill the "app".

Is there any way to check if this is malware/adware, or if it has sent off any sensitive data? What tools would allow me to do this? (If I can get into it's apk binary with any tool built into Kali Linux that would be great).

I've tried to disconnect all of my devices from the network and listen to sent/received packets with Wireshark, but still can't see whatever it is, due to play_store connection, and so on.. :(

Thank you, LeFizzy.

Setting up a proxy to view network traffic

  Is there any way to check if this is malware/adware, or if it has sent off any sensitive data? What tools would allow me to do this?

You can set up a proxy on your computer and set it on your phone, so you can see all the connections from and to your phone. OWASP ZAP is one possibility, and it's free. Download, install and start it. Then go to Tools > Options and select Local proxy on the left. Set the address to your computers internal network IP (usually 192.168.x.x or 10.x.x.x). Make sure your phone will be connected to the same network as your computer. Note the port (by default it is 8080, you can leave it this way). Click OK.

Now on your phone set this as a proxy. In your phone it might be different, but in my phone (Android 4.4) if I go to the wifi settings and click on the connected wifi it opens up the Network details page, scroll down and there is Proxy. Set it to Manual, then set the Hostname to your computer's IP (the one you used before) and the Port to 8080 (or if you have changed it, use that one). You can leave the Bypass for field empty.

From now on you will see all the http connections from your phone toward the internet in ZAP. To also see encrypted https traffic, you will need to add ZAP's root certificate to the phone's local certificate storage. To do this first go to ZAP, Tools, Options again and select Dynamic SSL Certificates. Click save and copy it to your phone's SD card. Then on your phone go to Settings, Additional settings, Privacy, Credential storage, Install from SD card, select the certificate file and add it. Please note, that your phone might have a different settings structure, so you need to search for Credential storage, most likely under Privacy or Security.

Now ZAP will also display your https traffic (unless certificate pinning was used by the app designer). ZAP will group the traffic by domain, so you can see what else your phone is doing apart from Google Play Services and alike.

Get the list of installed applications and their apk file

  If I can get into it's apk binary with any tool built into Kali Linux that would be great

Install adb

To get the apk file you can use the android debug bridge, adb. It is not preinstalled on kali, but you can easily install it. Based on this tutorial all you need to do is to run:

sudo add-apt-repository ppa:phablet-team/tools && sudo apt-get update

and

sudo apt-get install android-tools-adb

Setup your device driver(might be optional)

The next step is probably not necessary under kali, but under Ubuntu you need to do the followings:

Create an empty file in the /etc/udev/rules.d/ directory with the following name:

If you’re using the Ubuntu version Gusty/Hardy/Dapper, create the file with the name 50-android.rules. Execute the following command to do so:

sudo gedit /etc/udev/rules.d/50-android.rules

If you’re using the Ubuntu version Karmic Koala/Lucid Lynx/Maverick Meerkat, create the file with the name 70-android.rules. Execute the following command to do so:

sudo gedit /etc/udev/rules.d/70-android.rules

Type the following content in the editor and save it.

For Gusty/Hardy: SUBSYSTEM==”usb”, SYSFS{idVendor}==”USB-VENDOR-ID”, MODE=”0666″
For Dapper: SUBSYSTEM==”usb_device”, SYSFS{idVendor}==”USB-VENDOR-ID”, MODE=”0666″
For Karmic Koala: SUBSYSTEM==”usb”, SYSFS{idVendor}==”USB-VENDOR-ID”, MODE=”0666″
For Lucid Lynx: SUBSYSTEM==”usb”, SYSFS{idVendor}==”USB-VENDOR-ID”, MODE=”0666″
For Maverick Meerkat: SUBSYSTEM==”usb”, ATTR{idVendor}==”USB-VENDOR-ID”, MODE=”0666″

Source and vendor id here.

Enable USB debugging on the phone

This step is also for kali again: On your phone enable USB debugging in the Settings under Developer options. In Android 4.2.x and up Developer Options is hidden by default, to make it visible, tap seven times the Build Number (Settings > About Phone > Build Number), and developer options will appear.

Get the list of applications and the apk files

Now connect your phone to your computer via USB, and you can get the apk file with adb commands (as explained here):

1) Determine the package name of the app, e.g. "com.example.someapp".

adb shell pm list packages

2) Get the full path name of the APK file for the desired package.

adb shell pm path com.example.someapp

The output will look something like this: package:/data/app/com.example.someapp-2.apk

3) Pull the APK file from the Android device to the development box.

adb pull /data/app/com.example.someapp-2.apk path/to/desired/destination/on/your/computer


How is a second password better than TAN? Postbank will deactivate two-factor authentication via SMS-TAN in August. You are henceforth to instead provide an authentication password, optionally unlockable via (unspecified) biometry. One password thus authenticates all transactions. Everything is much better and more secure.

Now of course, we may assume that the experts inventing this system are not complete idiots. So obviously there's something that I'm not understanding.

What exactly is the advantage of a password that is indefinitively stored in some form (hopefully hashed in some way) on the server and stored (hopefully encrypted, but necessarily decryptable) on an easily-stolen device over a unique number that is generated on the fly, valid for exactly one given transaction, and expires within five minutes?

If your device is compromised (or “easily stolen”), SMS authentication is just as useless because an attacker can just read the message. The advantage of storing an encrypted password is that it’s hard to access (especially with biometrics), compared to text messages which can by default be read even on a locked screen.


Which information is revealed to a network-admin when using VPN? When I am using a VPN in a foreign network e.g. at my workplace or in an open W-LAN of a coffee shop, is it possible for the network admin to bypass my protection from the VPN?

How does it look like for the admin if I am using a VPN in his/her network?

They would see the initial communication to setup the VPN tunnel and they would see the source and destination communication to maintain the tunnel.  But all data within the tunnel, (IE where you were routed out the other end of the VPN) would be completely hidden.

Example: VPN from A(laptop) to B(VPN device) is visible.  The fact that you access stackexchange.com across the VPN is hidden.

Keep in mind, VPN can allow "split-tunnel" which ONLY routes traffic destined for the subnets on the other end of the VPN to go through the VPN tunnel.  All other traffic would go across your coffee shop network in their plain view.  To be secure, split tunneling must be disabled.
Ref: https://en.wikipedia.org/wiki/Split_tunneling

Edit:  Some additional thoughts...if at work (not recommended) your network administrator could have a proxy/NextGenFirewall that actually intercepts encrypted connections and acts at a Man-In-The-Middle to decrypt, inspect, and reencrypt as the traffic goes through.  Doubtful this would happen other places like hotels/coffee shops.


"Whatsapp Web is open in another computer or browser" - What should I do? I was using Whatsapp Web on chrome, and I got the message "Whatsapp Web is already open in another computer or browser".

What should I do?

Open Whatsapp in your handset.

Go to Options named "Whatsapp Web", Click on "Logout from all computers" & then try to login again.


Is a sensitive NAS behind a router safe? I have four pcs connected to a switch connected to a router that gets connected directly to the internet.

How safe is a NAS attached to the same router along with the switch plug?

I'd like to have the NAS available internally but safe from any intrusion (it contains sensitive data).

Edit: it was asked to add more details so here they come:
the four pcs all have Windows 7 OSes, they're modern machines, the copies are constantly kept up-to-date with OS updates. We only use Microsoft security essentials and no additional antivirus/firewalls to keep them light. The Router is a Netgear (can't exactly remember which model) with wi-fi capabilities (and the wi-fi is usually enabled, pcs don't use it though, nor does the NAS in any way).

If the NAS isn't directly accessible from the internet then the PCs are the weakest link.

An attack would focus on the PC. Then, with access to the PC, getting access to the NAS would be easy.

Attacking the PC first is easier, because
- They make connections to the internet regularly.  Web browsing and e-mail make good routes for an attacker.
- They are more complicated than the NAS, which often means more vulnerabilities.

Together this makes them much easier to hack than attacking the NAS directly.

If you have good security on the PCs (avoid dodgy sites, install good host security software and keep them patched ... ) then you are probably in reasonably shape for a small office or domestic situation.

And, I think obviously, as suggested in the comments. Disable the Wi-Fi if you don't use it.

I'm also assuming that:

You are only worried about remote intrusion.  You trust the people who use the computers and who have physical access to the system.
You aren't worried about, or have taken steps to reduce the chance of, the NAS just being stolen.  Old fashioned theft.
The router is configured securely (and kept up to date with security patches as well). And by configured securely that I mean it provides NAT and you haven't enabled any risky features like the 'DMZ' or 'port forwarding' options that cheap routers merrily provide. It also doesn't have remote administration enabled from the public internet IP address.

Could you get an intrusion?

So, you've taken steps to reduce the risk.  Running AV, using modern systems and keeping them patched goes a long way.

But an attack is possible.  Despite layers and layers of additional security, companies with systems connected to the internet get hacked frequently.

How could this happen?

You can divide the remote attacks into two categories.

Targeted attacks - where someone is specifically targeting your data.
Un-targeted attacks - where someone is trying to hack a bunch of computers, and by chance your computer is on their list.

Targeted Attack

Target attacks are expensive and/or time consuming activities for an attacker.

They might need to write a new virus, one that isn't detected by the Microsoft AV.  Then they could send it to you, via e-mail or perhaps a link to a web page.

It might need someone to click on the link, or perhaps they need to use a new vulnerability which hasn't had a security patch released yet.  These are known as zero day
vulnerabilities.

But these are expensive activities.  New vulnerabilities are valuable to attackers.  And writing viruses that bypass AV checks takes a little effort.  So you have to be a target that they knew about and were interested in.

From an article about attacks:

  Of the 18 attacks studied, 15 targeted 102 or fewer of the 11 millions
  hosts that were monitored. Eight of the exploits were directed at
  three or fewer hosts. The data confirms conventional wisdom that
  zero-day attacks are typically reserved for high-value targets.

(Full article: http://arstechnica.com/security/2012/10/zero-day-attacks-are-meaner-and-more-plentiful-than-thought/)

Un-targeted attacks

There's also the possibility that you get hit by a brand new attack, where you are just one of thousands of possible targets, using new vulnerabilities and/or viruses.  You'd be unlucky but it happens - but it does happen.

Though often they are just after quick financial wins - perhaps the password to your bank - or to encrypt your hard drive and demand a ransom for your data. Not every hack of this kind would result in them being interested in whatever is on your NAS.

So how safe are you?

It depends on how interesting your data is, and whether possible attackers know about it, as to whether a targeted attack is likely.  Perhaps you have some feel for this already.

I'm sure there are some stats on untarget attacks on the internet somewhere. I'll have a look for some figures.

What should you do?

Perhaps another interesting question is what else could you do if you want to be more secure. The resulting advice could form a reasonably long book.

The simplest solution: if the data is really really sensitive, don't connect it to the Internet. Don't access it from a computer that can access the Internet.

The practical alternative for the non-professional: Or, if you need the flexibility of connecting to the Internet, but still want real confidence about the security, get some security experts in, explain the level of security you need and have a detailed review done.  It's not cheap though - and you need to ensure you are getting good advice!


OpenSSL -nopad with ECB mode I was just trying to check if OpenSSL does use PCSK5 as documentation states when I got the following problem.
I first encrypted a plaintext and encrypted it using DES-ECB. I was expecting to see extra stuffed bytes in decrypted message but it seems OpenSSL is pretty smart and remove them before printing the result.
So I tried to use -nopad option, which

disable standard block padding

following official documentation. This way extra bytes did not seem to be removed and result is choerent with PCSK5. My question is: does that prove anything? Disabling standard block padding (PCSK5) does not disable padding so what exactly it does? What type of padding does it use?
Here are my tests:

Plaintext (What is the padding??????)
5B E0 A5 BD 8C CD F9 22 05 10 28 5C F8 6B 8D 22 6A 1F 06 A3 3E E7 C9 68 07 4E 92 AA >8D 07 EE AD
Decrypted (nopad)
57 68 61 74 20 69 73 20 74 68 65 20 70 61 64 64 69 6E 67 3F 3F 3F 3F 3F 3F 0A 06 06 >06 06 06 06
Decrypted (regular padding)
57 68 61 74 20 69 73 20 74 68 65 20 70 61 64 64 69 6E 67 3F 3F 3F 3F 3F 3F 0A

You can't see the padding in ciphertext because ciphertext is encrypted.

For commandline openssl enc, -nopad has effectively mirror meanings for encrypt and decrypt.

-nopad on encrypt means no padding is added (and the plaintext must be an exact multiple of the blocksize). You obviously did not specify -nopad on encrypt so PKCS5 padding was added by default (before encrypting).

On decrypt, by default PKCS5 padding is expected to be present and is removed; if the padding is not valid an error occurs. -nopad means no attempt is made to remove padding; if padding is present, as in your ciphertext, it is left in the data as you saw. If encrypt was done (successfully) with -nopad you need -nopad on decrypt so you don't try to remove padding that isn't there and fail.

PS- You are aware that single-DES has been broken and obsolete for years now, and ECB mode frequently allows system breaks unless used with great care?

Lessons learned and misconceptions regarding encryption and cryptology

Block chaining modes to avoid

How are chosen plaintext attacks against ECB implemented in the real world?

https://crypto.stackexchange.com/questions/12510/ecb-weakness-and-its-exploitation

https://crypto.stackexchange.com/questions/11451/can-ecb-mode-really-leak-some-characters


What is the idea of passwords with random buttons position More and more web sites use for an authentication some digits keyboards with random position instead of password. Like this

Could someone explain me the idea of this instead usual login and password?
I have an idea that it seems to be more secure because if you capture traffic of someone you'll get only coordinates clicked and these coordinates are different every time.
But in this case server should transfer the positions of each button to a client to make last be able to display it correctly (4 is top left corner, 8 in bottom left, etc)
If the traffic can be captured so we can capture the position of each digit and coordinates clicked after.
Why is it more stable that common login / password with htts enscrition?

Other answers have talked about key loggers, and how they would defeat this mechanism, but I can think of other attacks it would protect against:

Looking at the grease marks on a touch screen where somebody regularly enters the same code. For instance, the code to unlock a phone, or a door entry system where the screen isn't used for anything else.
Shoulder surfing, where the attacker can see the movement of the user's hand, but not what's on the screen. This could be somebody physically behind the user whose view is partially obstructed, or it could be a camera that doesn't have the screen in its field of view.


Nonce in Aes-gcm AAD I have some data which I'm encrypting using Aes-Gcm.
Every time I have to encrypt the data, I generate a random nonce of the appropriate size, as well as an empty array for the tag data.
In Aes-Gcm, there is an option to provide AAD, or Additional Authenticated Data. To my knowledge, AAD is basically some plaintext data that is authenticated when you decrypt using Gcm.
Normally I believe you just prepend the nonce in plaintext.
However, since the nonce is generated before the encryption is called, I was wondering if you could pass in the nonce as the AAD.
Would this be a security risk? Would it help? Or would it not matter at all?

I don't know if passing nonce as AAD would be security risk, I don't know much about the maths behind Galois authentication to answer it, other people in crypto SE might be able to answer. But you don't actually need to do that. All you need for GCM is use the same AAD used during encryption, during decryption if you want to pass authentication. AAD can be some plaintext and kept with the cipher just as nonce, why do you need to do that anyway? You can use any general tag as AAD. It only saves a few bytes/kilobytes of storage while possibly risking. And AAD is optional too, you can use GCM without AAD. What you should never do, however, is repeat nonce for the same key, it destroys both confidentiality and authentication provided. GCM is streaming mode cipher and nonce reuse has more devastating consequences than modes like CBC. I would also recommend you look GCM-SIV mode, which can help guard against IV reuse due to poor entropy source used by your random number generator. There are recommendations for using identifying information in GCM to prevent replay attacks.
EDIT:
Another option if you do not need to worry about replay attacks: You can also use constant AAD for one use case. It is not a security risk and does not require transferring AAD. It also prevents using one piece of encrypted data from being used in another context in case the format happens to match