SQL Injection - UNION SELECT and returning a 'keyword' to find exploitable columns I have a problem I'm hoping someone could help with regarding the use of UNION SELECT, in a scripted/automated way to find columns that are exploitable (having already found the number of columns using ORDER BY)

Doing this manually

Using http://www.site.com/index.php?id=-2 UNION SELECT 1,2,3,4,5,6,7,8-- I am aware I can manually view the column numbers that appear on the page to find the columns that are exploitable, but it is extremely difficult to try and parse these out of the response content or page source using a script in an automated way to find the expoloitable columns that are revealed (unless someone knows of a reliable way this can be done?).

Automating this using a scanner/fuzzer

In a few scanners/fuzzers and sql injection tools I have found some references to getting the UNION SELECT to return a specific 'keyword' on the page which will indicate that this particular column is exploitable if that 'keyword' is then found in the response-content....

For example:

http://www.site.com/index.php?id=-2 UNION SELECT "EXPLOITABLE",2,3,4,5,6,7,8--   <-- The word EXPLOITABLE did not appear on the page content so this column is not exploitable
http://www.site.com/index.php?id=-2 UNION SELECT 1,"EXPLOITABLE",3,4,5,6,7,8--   <-- The word EXPLOITABLE did not appear on the page content so this column is not exploitable
http://www.site.com/index.php?id=-2 UNION SELECT 1,2,"EXPLOITABLE",4,5,6,7,8--   <-- The word EXPLOITABLE **DID** appear on the page content so this column **IS** exploitable
http://www.site.com/index.php?id=-2 UNION SELECT 1,2,3,"EXPLOITABLE",5,6,7,8--   <-- The word EXPLOITABLE did not appear on the page content so this column is not exploitable
http://www.site.com/index.php?id=-2 UNION SELECT 1,2,3,4,"EXPLOITABLE",6,7,8--   <-- The word EXPLOITABLE did not appear on the page content so this column is not exploitable

and so on until it reaches the last column number 8.......

The 'keyword' being a word that would not normally be found on a webpage so that false positves are prevented e.g EXPLOITABLE, InJeCtAbLE, AASSDDFFGG (or any variable you want).

The problem I am having:

As I am writing an sql injection tool/fuzzer I am looking to find the best way to find these exploitable columns in an automated/scriptable way and the most logical method seems to be the one described above using the 'keyword' (unless anyone can suggest a better way)

This is because I can then just GET each url with the UNION SELECT and the 'keyword', store the response-content and then see if the variable 'keyword' I used appears in the response-content. If it does then I will know it is exploitable, if not I will then move onto the next url and so on until the script has tried this on all column numbers.

Would this be the best/most reliable method to determine exploitable columns using UNION SELECT or can you suggest any better method to use?

This is one of the best ways to do it, but be careful of error-based injection issues. You might find that every single result displays the random token in the output because each column is bound to an integer result, and a string will cause a cast error. In such a case, the only way to detect it is to look for typical SQL server / MySQL / PostgreSQL error messages in the output, and look for a different count of the token in the page.


How can TOCTTOU vulnerabilities within the Windows OS be mitigated? What are some ways to mitigate the time-of-check-to-time-of-use issues that apply to Windows permissions?

Example:

End-user is added to the local Administrators group in order to install software, printers, etc.
The user's account is removed from the Administrators group while the user is logged in.

The change in permissions will not apply until the user's next login.

The user, with Administrator rights still applied, adds themselves back to the Administrators group before logging off - reversing the removal.
The next time the user logs in, they still have Administrator permissions until they are (and stay) removed again.

Aside from just not granting Administrator rights to end-users in the first place (obvious solution), or by any other means that require specific end-user actions, what are some ways the above scenario (or similar Windows-inherent TOCTTOU issues) can be prevented?

Without actually answering the declared question, I want to address your given example - because I think you're actually just trying to solve that issue, and not the generic issue.

Once you grant administrative privileges to a user - it's done with, you aint never getting them away again.
As you say, the user can just add himself back into the Administrators group...  But there are actually many, many other ways he can do ensure that he keeps his privileges, while he still has the privilege, such that you would be hard pressed to remove it, even if you happened to have full and complete system auditing turned on.

For example, he can create another user, and add that to Administrators.
Or reset the password on Administrator, and enable that. (Since you don't use it, right??, you'd never know...)
Or create another group, make it hidden, and add that as a member of Administrators.
Or, simply setup some Windows Service, or MSTask etc, running as LOCALSYSTEM.
Or install some kinda rootkit.

Of course the system auditing won't really help, since and Admin can easily shut that off, temporarily...

I could go on, but I hope I already proved my point... TOC-TOU is not your problem here, it's granting temporary administrative privileges (not really possible), or maybe dealing with malicious administrators (Really Hard Problem) in general.

As you said, don't grant Administrator privileges to end users. There are other solutions to enable them to install programs.


Office 365 "ForeignRealmIndexLogonInitialAuthUsingADFSFederatedToken" I've detected a number of illegitimate logins to Office 365 (based on Client IP).  In the audit log, the operation is listed as "ForeignRealmIndexLogonInitialAuthUsingADFSFederatedToken."  I'm not terribly familiar with this logon type, and the MSDN articles didn't seem to provide the depth, only that it exists.  Can anyone explain what this could possibly mean?

This is a fairly horrible entry in the combined audit log and Microsoft certainly don't make it easy to decipher.

It appears to happen when a users device with an on-prem AD account sync'd to Azure AD tries to authenticate.

From what I can tell, the IP address should be related to the client device - which may itself not be on-prem at the time of authentication.

There are a couple of support articles related. As often the case with MS web support, they are fairly inpenetrable. 1, 2


Can a password change via CSRF lead to account takeover? If a website has a password change functionality where the user isn't prompted for the current password and the form isn't using tokens to mitigate CSRF attacks, an attacker can easily execute a CSRF attack on logged-in users so that the victims are tricked into changing their passwords.

But, given no other flaws on the web application, can the attacker learn the victim's username so that he can actually login with the new password set by the attacker?

Yes.  Imagine spearphishing a high-profile user whose username you already have. All you need is to send them to your crafted CSRF page and you have taken over their account.  Or equivalently, a mass phishing campaign if the web application accepts your email address as an alternative username.

CSRF on security-critical flows is incredibly dangerous.  You are counting on username behaving like a secret value when it (nearly always) does not.  Also see user enumeration vectors, etc.


How can I check if a Mac application has NX or ASLR enabled? According to Wikipedia, the NX bit is set for all x64 binaries:

  OS X for Intel supports the NX bit on all CPUs supported by Apple
  (from 10.4.4 – the first Intel release – onwards). Mac OS X 10.4 only
  supported NX stack protection. In Mac OS X 10.5, all 64-bit
  executables have NX stack and heap; W^X protection. This includes
  x86-64 (Core 2 or later) and 64-bit PowerPC on the G5 Macs.

However, what if the executable is is not 64 bit: Mach-O executable i386?

Similarly, for ASLR, Wikipedia says that it's enabled by default for 10.7 and up:

  In Mac OS X Lion 10.7 (released July 2011), Apple expanded their
  implementation to cover all applications, stating "address space
  layout randomization (ASLR) has been improved for all applications. It
  is now available for 32-bit apps (as are heap memory protections),
  making 64-bit and 32-bit applications more resistant to attack."

Does this mean there is no way to opt-out of it via a compiler option?  If there is, how could I verify that the application has not?  Are there any analogies to Windows, where some libraries may be ASLR-ed, but others not?

NX bit is for AMD architecture and XD is for Intel. You want to know if a page is executable, basically. vmmap <pid or partial process name> will list out memory chunks permissions.
You can check for ASLR (PIE, to be correct) in OS X by using otool -hv <file_path> and checking out the "PIE" flag.  For example my i386 Wireshark has no PIE flag (most probably b/c it was compiled without one). I don't know how it is in 10.9, but in 10.7 you could link your program with --no_pie flag to disable PIE.

There's an interesting script at https://github.com/electron-archive/brightray/blob/master/tools/mac/change_mach_o_flags.py which can answer your question. You can actually use it to opt-out already compiled binaries with --no-pie flag to the script. Let me cite a part of it and invite you read the full source:

  ...

  NON-EXECUTABLE HEAP

  Traditionally in Mac OS X, 32-bit processes did not have data pages set to
  prohibit execution. Although user programs could call mprotect and
  mach_vm_protect to deny execution of code in data pages, the kernel would
  silently ignore such requests without updating the page tables, and the
  hardware would happily execute code on such pages. 64-bit processes were
  always given proper hardware protection of data pages. This behavior was
  controllable on a system-wide level via the vm.allow_data_exec sysctl, which
  is set by default to 1. The bit with value 1 (set by default) allows code
  execution on data pages for 32-bit processes, and the bit with value 2
  (clear by default) does the same for 64-bit processes.

  In Mac OS X 10.7, executables can "opt in" to having hardware protection
  against code execution on data pages applied. This is done by setting a new
  bit in the |flags| field of an executable's |mach_header|. When
  MH_NO_HEAP_EXECUTION is set, proper protections will be applied, regardless
  of the setting of vm.allow_data_exec.

  ...

On top of that I have to add a link to SO page with two very good answers related to the issue: https://stackoverflow.com/questions/12824045/what-exactly-is-randomized-with-aslr-in-macos-x-and-ios


Where you can run shellcode inside an ordinary process, what is a stealthy way to leverage that to get offensive Powershell code running from it? Right now, offensive use of Powershell is one the hottest topics in infosec. Powershell scripts are most often pitched as being appropriate for the "post-exploitation" phase of a penetration. This question follows somewhat along those lines, except it involves taking a step toward using Powershell a bit earlier than usual: when the only foothold you've gotten so far has been from getting an application to run shellcode of your choosing.  (Call it " very early post-exploitation" if you like.) So:

Let's say you are in a situation where you have gained the ability to execute assembly shellcode (with no size limit or character restrictions) inside a certain process on a Windows machine. You want to leverage that ability not to directly run lots of low level code, but to do something quite different: to create a execution environment inside that process where you can run Powershell code.

The reasoning behind that choice is pretty simple: setting up a Powershell execution environment allows you to take advantage of all of the ever-increasing Tools, Tactics, and Procedures that use Powershell that the security community now has produced/is producing.  And setting up that environment within a process that's already running allows you to avoid starting a new process to run the Powershell code (and especially avoid starting powershell.exe, cmd.exe, or wscript.exe) like most lower-skill pen testers and bad guys will often do, something that can be very, very suspicious to a defender that is monitoring event logs or is using well-configured HIDS/HIPS software.  The overall goal is to replicate some of the capabilities and stealth of some higher-end attackers without having to much custom programming work in low level programming languages, instead taking advantage of the universe of Powershell scripts/tools that already exist.

I know that the general concept of what I'm interested in doing here works, because I've been able to prove it out, using (for example) Metasploit--specifically with adllinject payload that starts from shellcode generated by msfvenom-- along with a reflective dll (from Empire, for eg.) to successfully get a Powershell agent up and running without creating a new process in a number of test situations. But, to be frank, I'm a little skittish about the idea of using anything that relies on Metasploit payloads or communications for something that might eventually (hopefully) be used during an actual engagement against a defender with HIDS, HIPS, NIDS, etc.

Are there alternative tools/methods that might be quieter while accomplishing the same result--getting Powershell code running on a target where you already have some code execution and without creating a new process that might be easily detected? I'm open to considering pretty much anything that doesn't require writing a lot of custom code in assembly. (Though, of course, more straightforward to implement is always preferable.)

If I understood correctly what you want, you could try mapping a writable page, writing code to it, switching it to executable, and then you just execute it (and it can be your PS or anything). Use VirtualAlloc instead of Malloc to obtain memory-write permissions with PAGE_EXECUTE_READWRITE. Do not forget to set the execution flag using VirtualProtect after writing to the memory but before finally executing it. Such a tactic should work for your objective and no new process is involved.


Is it okay to save passwords as base64 strings with no other hashing or encryption beforehand? I've just inherited a project where all the passwords on the server side are simply converted to base64 and put in the database. No salt, no hash, nothing. Just a simple db.Add(password.ToBase64) kind of process.

Surely anyone who gets their hands on that data can extremely easily decode it? Hence the usual salt/hash approach.

I questioned the decision to use base64 strings and was told:

  Regarding password - If someone is already on your server, you are already under threat irrespective or the encryption you choose. Its same even with someone penetrates your SSL layer itself.

This seems to ignore the fact that hacking into a server is not the only way to access a database. It could be as easy as going through someone's unguarded computer, stumbling across a database backup and seeing the blindingly obvious base64 strings, then joyously converting them all to raw passwords.

I know this question is probably a little bit too open-ended for the ususal StackExchange format, but the issue doesn't seem to be very well covered on here with the question wording I've used. It's a pretty important topic so I thought I'd throw it up.

To me it's utterly obvious that passwords shouldn't be stored using only base64 conversion, but I'm still relatively new to all this so maybe I've missed something.

Thanks.

TLDR: Never store passwords as base64, so you are correct in that it is a very bad practice.

  Surely anyone who gets their hands on that data can extremely easily decrypt it?

Well, there is nothing to decrypt. Base64 is not an encryption, it is an encoding. It's role is to make sure the password can be stored in the database nicely and special characters aren't a problem. It does nothing to protect the password. From security standpoint, it is exactly the same as storing it without any encoding.

  This seems to ignore the fact that hacking into a server is not the only way to access a database.

That quote seems to ignore a lot of things. There are several reasons to hash passwords and they have nothing to do with preventing initial compromise of your server. As mentioned, hashing does nothing to prevent that. Here are some reasons to hash passwords:

If your system is temporarily compromised, it allows you to recover. Thing about this scenario. Your server is compromised and your database stolen. Yes, all the personal data about your customers is leaked, nothing to do about that. But if the passwords are hashed, you can just send an email to all your customers urging them to change their passwords once the compromise is resolved. You have some level of certainty, that the user who knows the password and has access to the email is the proper user, as the attacker does not have the passwords.
If your system is compromised, it protects your customer in case they use the same password on multiple services. The first thing an attacker may likely try to do with a leaked DB of plain-text passwords is try the email password combination on popular sites like Facebook.
Someone with legitimate access to the server may use someone else's password to mask his tracks. Imagine a scenario where an admin has full access to the server, but everything he does is logged. If he tries to do something nefarious, it would be easy to figure out it was him. But if he just pulls a password of a different users, that may not be easy or even possible to figure out.
Limit a compromise. An attacker that gained access to the DB may not have full access to the server. However, if he can pull admins password from the database and log as said admin or even just other users, he may get access he would not be able to get otherwise.


Does using WPA2-Enterprise just change the attack model vs WPA2-PSK? As far as I can tell based on the reading I've done so far, WPA2-Enterprise uses the same encryption and security algorithms and methods as WPA2-PSK, with the addition of using another service for authentication.

Is this accurate, meaning that a WPA2 Enterprise WiFi network is just as susceptible as a WPA2 PSK network to brute-force and dictionary/pre-computed attack? In fact, wouldn't it mean that a WPA2 Enterprise network is more susceptible to such an attack as the number of users increase?

It doesn't appear too difficult to setup an authentication service. That being the case, do I gain anything security-wise by using WPA2 Enterprise?

WPA2-Enterprise is (in my opinion) considerably more secure than PSK.  Reasons

WPA2-PSK has a single shared key amongst all devices.  that means that if one of the devices is compromised the key is lost, so the more devices you have the risk of loss or compromise increases.  As against this WPA2-Enterprise has per user secrets, so not the same problem.
Using WPA2-Enterprise each user can change their credentials as required, whereas with WPA2-PSK changing the secret could be a major undertaking, depending on the size and make-up of the user/device population.  This increases the potential severity of a compromise as key rotation will be much slower (in most cases) than password rotation so if a credential is compromised, it's likely to remain so for longer with PSK.
With WPA2-Enterprise you can make use of stronger authentication mechanisms (e.g. 2-factor if needed)
With WPA2-Enterprise you can add certificate authentication to stop random attackers brute-forcing the users creds to get access.


Remaining disk size with plausible deniability There is a problem with plausible deniability of TrueCrypt / VeraCrypt which bothers me for quite some time. Since the software must not show any hints about whether a hidden volume exists inside the main volume, how can it decide, how much free disk space is available in the main volume?

Does it just override the content of the hidden volume, when we store too many data in the main volume?
Does the size of the hidden volume change dynamically, when we store more files in the main volume?
Does a fragmented main volume increase the danger of overwriting the hidden volume?

The elements are provided on the wiki page on Hidden volume. The outer volume and the hidden volume share the same lower level space, and at creation time, the size of the hidden volume was computed to not overwrite existing data in the normal volume.

But to allow the plausible deniability, nothing in the outer volume can be aware of the existence of a hidden volume when it is opened normally (*). So if you add a lot of data into it, you are likely to overwrite the hidden volume and destroy all of its data.

Said differently, when confidentiality is important, a hidden volume is fine, but not when availability or integrity is the major concern. But even when you know that, using a hidden volume is not a trivial operation. Because you must:

use the outer volume on a regular bases to avoid to show that it is never used => which would be an hint that is is only there to contain a hidden volume and would break in piece the plausible deniability
never let the system file grow in the outer volume in order not to destroy the inner one (*)

(*) As it would be complex to use the outer volume and at the same time be sure not to damage the hidden one, VeraCrypt offer the possibility to make the outer volume aware that it contains a hidden one through a mount option requiring both passwords. When you use the outer volume that way, you cannot erase the hidden one. But someone looking at your computer at that moment will also know that it contains a hidden volume.

So you must be prepared if you have to reveal the outer volume to only open it in normal mode and use it normally even if it can destroy the hidden volume.


Who owns this bit coin address? If I have a bit coin address, how do I find out user info? I see there is a http://bitcoinwhoswho.com  but I did not get any information back on my user.

Here is what the address kind of looks like (some substitutions) 6cc711d3e7c71b49304d5d8312f739d14807aa8d5eca4e98c18000ccf2e7b2d

Thanks

Well, you can look at the transactions for every single bitcoin transaction that has ever happened, but that doesnt mean that the transactions will actually reveal the information about the wallet holder, other than their public key.

If you want to learn more about what transactions that account has been involved with, you can check out: Blockchain.info  or Block Explorer.

If you want to find the personal details about the account holder, you will probably need a warrant and go knocking on the exchanges associated with the account you have in mind.


Prevent my site to be sniffed and changed by man-in-the-middle-attacks I want to secure site which is locally used for Prepaid Services, the site has been hacked many times, for the first step, I implemented SSL and its now working fine, however, I want to be sure that attacker can't get user data in transit because many users connecting to the site from restaurants or public places.

One scenario: Using BackTrack attacker can redirect all HTTP traffic to single IP and show fake page to user, I knew browser shows SSL error, the best way to prevent this attack is to educate user, however, I want to ensure that there is no other way that attacker can attack the site anymore.

Update: I planned also to implement PIN verification (Sending random PIN by SMS for extra verification)

SSL/TLS only protects against data inflight, implementing it won't change the attacker's ability to directly attack the site.  TLS will protect against an attacker being able to see the data (confidentiality) and modify the data (integrity).  However, as you've discovered, it's possible for an attacker to actively MITM and present an invalid cert to the end user, and if the end user accepts it, then all bets are off.  HTTP Strict Transport Security (HSTS) can help prevent this by requiring that all future visits go over HTTPS, and may (depends on the browser) change the behavior of the browser when receiving an invalid certificate.  Chrome, for example, will not present a "continue anyway" button for a certificate error against an HSTS site.

All that being said, active attacks against SSL/TLS are relatively rare (sorry, no numbers to back that up at hand) and are hard to conduct on large scales (as they are usually close to the end user, so only get a small number of users).  Phishing, typo squatting, or other similar mechanisms are far more likely to cause you problems.

If you want to make password capture (whether via SSL/TLS stripping or interception, phishing, or otherwise) less valuable, implement strong two-factor authentication, such as HOTP or TOTP.


Didn't log out of YouTube - Is this a problem? Recently, when staying in a rented apartment, I signed in to the YouTube app on the smart TV by entering a code using chrome on my tablet to pair them.  I was planning to log out before I vacated the apartment but forgot to do so.

What are the security implementations of this?  I am not bothered by people seeing my viewing history on YouTube etc., but obviously wouldn't like anyone to access any other google services via my account.

I am quite sure that the SmartTV cannot share your account session with other devices, but in any case you can remotely close the session by following the guide here: https://appuals.com/sign-google-account-remote-devices/


Chrome generated passwords not high entropy? On Chrome, if you open a sign up page, it will offer to fill and remember the password field. I did this and got the following sequence of passwords offered as generated:

suCipAytAyswed0
LUnhefcerAnAcg2
it2drosharkEweo
UndosnAiHigcir0
AKDySwaybficMi5
DorrIfewfAidty5
MeecradGosdovl9
KasEsacHuhyflo4
OngouHemNikEyd0

In all of these, there is only one digit, and in all of them except the third the digit is at the end. The chance of me getting that many with this exact pattern is extremely low, and I've seen it in other passwords generated by Chrome, so I'm confident it would continue if I generated some more.

This just seems weird, wouldn't it be easier to generate the password as a random collection of letters and numbers than to enforce some strange pattern; given that these are not supposed to be remembered? Why would Chrome do something else?

Conor's answer is a good starting point, but if you dig into Chromium's source the situation starts to look a little bleaker (but still better than not using a password manager at all).

Chrome 68 (current version as of August 1st, 2018)

Up through version 68 Chrome follows FIPS 181 to generate a 15 character pronounceable password allowing uppercase letters, lowercase letters, and numbers. If the result doesn't contain both an uppercase letter and a number, it changes the first lowercase letter to uppercase, and changes the last lowercase character to a random digit.

Unfortunately the entropy of a FIPS 181 password is pretty hard to calculate, as it generates variable length syllables rather than characters, and there are a bunch of rules dictating whether or not a syllable is allowed.

The non-uniformity has severe implications. A 1994 paper (page 192) estimated that to break into 1 out of 100 accounts with 8 character passwords, an attacker would only have to try 1.6 million passwords. Even if increasing the length from 8 to 15 doubles the entropy, that's still probably under 60 bits of entropy on average1, though this is improved slightly due to capitalization.

The original standard doesn't appear to support uppercase letters or numbers, and the implementation2 only capitalizes the first letter of a syllable with a 50% chance (interestingly y is replaced with w in the array of characters checked, so y will never be capitalized). This means that rather than adding about 1 bit of entropy per letter, capitalization only adds 1 bit per syllable. The number of syllables isn't constant, so it's hard to determine how much entropy this actually adds, but given the scarcity of single letter syllables it almost certainly adds less than 8 bits on average.

Numbers and symbols are supported by turning each single letter syllable alternately into a digit or symbol with 50% chance (though the symbol feature isn't used). Unfortunately, as you have noticed, single letter syllables are uncommon3, so ForceFixPassword usually ends up swapping out the last lowercase letter for a digit.

There may be more issues, but I'm getting a bit tired of looking at it. In short, this isn't a very good method of generating passwords, and the entropy is significantly less than one would expect for the length. In practice this is still probably ok for the average user, as it means they won't be using their favorite low entropy password in 20 different places, but breaking it is definitely possible for a determined and funded attacker with a fast hash (ie not a good password hash) of the password.

Chrome 69 (scheduled for release in September)

Things are looking much better in Chrome 69. The character set is upper and lowercase letters, numbers, and the symbols -_.:! with the following removed for readability:

l (lowercase letter L)
I (capital letter i)
1 (digit one)
O (capital letter o)
0 (digit zero)
o (lowercase letter O)

The generation works by adding a random character from each class until the minimum count for said class is met. By default and as currently used this is one lowercase character, one uppercase character, and one digit.

Then the rest of the password is filled with random characters evenly chosen from all character classes (respecting a maximum count for each class, currently unused).

Finally, since characters were added to the beginning of the password from predictable classes in order to satisfy requirements, the string is randomly shuffled. The shuffling happens up to 5 times if two dashes or underscores are adjacent in order to improve readability, so this will very slightly reduce the entropy, but the reduction is so slight as to be unnoticeable (and removing dash or underscore from the allowed symbols would be worse).

With 61 possible characters a fully random password would have log2(6115) = 88.96 bits of entropy. Using inclusion-exclusion to account for the required characters, I come up with 88.77 bits of entropy:

61^15          all possible passwords
-53^15         passwords without digits 2-9 (0 and 1 are excluded)
-37^15         passwords without lowercase letters (l and o excluded)
-37^15         passwords without uppercase letters (I and O excluded)
+29^15         add back passwords excluded twice for lack of digit and lowercase
+29^15         add back passwords excluded twice for lack of digit and uppercase
+13^15         add back passwords excluded twice for lack of lowercase and uppercase
-5^15          remove all-symbol passwords that were excluded then added back

The extra shuffling will shave off a fraction of a bit as well, but I don't have time to calculate it right now. In the end, the password should have over 88 bits of entropy, which is pretty good.

The old generator still exists in version 69, but when I tested the dev build it was using the new one. Whether or not there's any way to use the old generator I don't know.

1. Average entropy isn't necessarily useful with non-uniform distributions, the original 1975 paper gives an example (pages 29-30) of a generator that produces a single password (e.g. "password") with a 50% chance, and a high entropy password otherwise. The average entropy may be high, but there's still a 50% chance the password will be guessed immediately. Even so, extrapolating from the 1994 analysis, I believe it should still have well over 40 bits in the worst case.

2. The implementation isn't actually Chrome's, but is taken from the APG program, with minor modifications for compatibility

3. Testing with apg reveals that single letter syllables actually occur in about 33% of passwords, but 70-75% of those only have a single letter syllable at the end.


Monitoring file copy on external devices Transferred a personal folder from an external HDD to a USB using my
  work PC. Just used a simple cut paste method between the two drives,
  never writing anything to the internal HDD. However, come to find out
  there were some content sensitive pictures within the folder I was
  unaware of as it was an older external drive and I wanted to salvage
  some things before discarding it. Anyhow, I never actually opened the
  files, so no thumbnail cache was created and I am not too concerned
  about having any kind of trace files on the PC.

However, I know my company could probably log this event, etc, but is there anyway the could have captured the files within the folder itself that I moved? I am a model employee and am regretting my lack of judgement in this scenario.

Does anyone have any ideas on something I may have missed or if I should be worried. Thanks.

Corporate technologies to do that include Data Loss Prevention (DLP) for example.

But scanning for "hot files" that are not even written on disk, there's a 0.01% chance your employer will log and review it.


Authorization Header in dev tools My web application need to make call to 3rd party REST API which is protected by Basic authentication on some user click. We are planning to use a technical user for the call.
This will expose the Authorization header in network call in browser dev tools.
How can avoid exposing the authorization header to the user?

Short and simple answer: You can't.  HTTP headers are sent by the user agent on behalf of the user, and cannot be hidden from the user.
So in a case like this, it's probably better to "proxy" the call to the 3rd party through your own API and rely on the authentication you use for your own users.


WPA2-EAP-TLS with global client certificate Is security compromised if every client uses the same client certificate to authenticate with WPA2-EAP-TLS?
In essence, we want to provide an open wifi network, but want to ensure users cannot see each other's traffic. With WPA2-PSK, this appears to be impossible.
As users are expected to have our app installed, the option we were thinking of is using WPA-EAP. Since WPA2-EAP-PSK is unsupported by almost every device, we were looking for an alternative.
EAP-WPA2-TLS seems to be an option, the question is: Can we deliver every client the same certificate, or do we need to ensure each client has their own certificate?
Authentication is not a concern, this is only relevant for data security.
It appears that the PTKs are generated using the certificate, but I'm unable to determine if that is the only source or if other data is used to generate the keys that would still guarantee unique encryption keys.

Since you don't care about authentication, why not use OWE (opportunistic wireless encryption) instead of WPA2? If your hardware supports it, it provides an open network that encrypts each client's traffic. There would be no need to mess with certificates.


Is vlan considered a security feature? Possible Duplicate:
  Why do people tell me not to use VLANs for security?

This topic came up in a discussion about network infrastructure, where a company had moved from separate physical network zones to virtualized zones using vlan technology.

My colleague stated this was a security feature, where they trusted the technology to efficient separate zones the same way as a physical separation would. No encryption was involved at the network level.

So, is VLAN considered a security feature?

VLAN is by design not a security mechanism, but it can be used as such if the underlying network hardware (and its maintenance) is mutually trusted by all stakeholders. In that case, the provided isolation is reliable.

To my knowledge, server hosters ("cloud providers") use VLAN to provide isolated networks to their customers. ISPs also sell (non-cryptographic) MPLS as cheap/efficient VPN solutions. If the infrastructure is trusted and the perimeter is secure, this can be done.


Is there an alternative to TCP/IP that encrypts end-to-end? If there was a communication protocol that encrypts at the very low-level, this would solve the problem of wiretapping entirely and for all.

If there was a communication protocol that encrypts at the very
  low-level,

There is: IPSec

  this would solve the problem of wiretapping entirely and for all.

It doesn't.


How do I protect myself from the aftermath of the OPM hack? As a federal employee, I, along with some 4 million other Americans had our information compromised in the recent OPM (office of personal management) hack. Former and current addresses, names of friends and family, salary information, and maybe even social security numbers may have been compromised.
What can I do to protect myself and others from the malicious use of my (and coworker's) info? While I know spear-phishing is a likely path anyone after more information may take, what are some other common attacks that follow hacks like this, and how do I recognize and defend against them?

OPM has released statements offering credit protection and advice on how to respond. Phishing e-mails were listed as one of their concerns. Their recommendation was to use anti-phishing plugins to your web browser to help identify phishing e-mails and keep your systems patched. For the layman, that's probably the best you can do.

I believe it's important to understand what the perpetrator would want to do with this kind of personal information.

Note that this isn't the first compromise of clearance information. Two contractors, USIS and KeyPoint have been compromised over the last few years. I've found little written about why they were targeted.

Regarding the motivations behind the OPM compromise, I've seen two trends in the media. One concern is about blackmail and another about social engineering.

Wired has a nice write up on why someone would go after this information. They claim the information could be used by foreign intelligence services to blackmail people in to turning over secrets. Remain vigilant regarding that risk and report it to authorities should you think you're being targeted.

The data that was taken is a treasure of social connections. Your neighbors, parents, co-workers -- all people you trust and would expect to receive messages from. If you are concerned you are being targeted, contact the FBI Internet Crime Complaint Center (IC3) listed in the OPM statement You can also take extra precaution to validate all e-mail attachments you get (especially Office and PDF documents) with the receiver.

One last thing to consider -- this might not actually be about you and I. It may be about identifying and punishing those who are talking to the US government without permission. The Wired article talks to that a bit.


Can 3rd party AVs have accessed to my Windows PC and Android phone even after uninstalling and removing them? Before we start this, I have paranoia issues (doctor diagnosed, not self-diagnosed) so things might at some points seem like an extremely far reach, but please bear with me.

I bought an AV yesterday (prefer not to name it), after reading site reviews about it and getting a few recommendations about it. But after buying it, I stumbled across some user reviews and a lot of them were talking about abysmal customer support and shady business practices. Not only that, but when making an account on that AV's site, it was riddled with issues ("Invalid email"), and then after somehow making an account, when I tried to log in, they kept saying "invalid username or password". So I clicked on the "forgot password" option, entered my email and submit and they never sent me an email to reset the password. So I just logged in using my google account tied to that same email. After that, I downloaded and installed it on my Windows PC and Android phone, and unfortunately it was then I saw the user reviews which were abysmal, and I realized it was kinda poor for me too.

I emailed their customer support asking for a refund, and removed it from my phone, and uninstalled it from my PC. Then I had to restart my PC to complete uninstallation, and after restarting, the AV was back on my desktop, and on the "apps" part of settings. So I google searched and downloaded their own uninstaller and uninstalled it, and after it uninstalled, it said "uninstalled with errors, contact customer support to complete uninstallation". I felt I can't bother with that, so I just to restarted the PC, looked to see if it was still there, and then clicked on "This PC" and typed in the AV's name in the search tab and shift deleted every single file with the name of the AV.

After that, I restarted again and realized my PC was considerably slower. BIOS time before installing the AV was around 2 seconds, but after installing and uninstalling the AV, BIOS time is now 4 seconds.

Now all this; the shady business practices, the poor customer support, the uninstalling difficulties, the difficulty and errors faced when trying to make an account, and the BIOS time slow down even AFTER UNinstallation, makes me worried about if these guys are still in my PC and phone and are maybe accessing the deepest corners of my pc and phone. I gave them access, what's to stop them now?

Can they still access my PC, phone, and also maybe my google account? Do they still have access to my PC and phone? Could they hack me or something?

And if so, how do I completely purge their existence from my phone and PC? How do I get my PC  back to normal? How do I stop them from accessing my PC? How do I make it as if it was never installed in the first place?

P.S. This AV is quite a reputable software, review sites love it always gets great reviews from testing labs and so on and it has hundreds of millions of users worldwide. So it's not some unknown AV.

If you run software on your PC it can do anything with the permissions you grant it. If you install or uninstall an AV this is usually done with system permissions - and like any other software running with system permissions it can do a lot of harm and also embed itself deep into the system if it really wants to.

If you don't trust the AV vendor you should not trust its product, the software which installs the product and the software which uninstalls it either. It could in theory do anything with your system (including spying on you etc), which of course does not mean that it will actually do it in all cases. Given that you say that the AV is from a reputable vendor (even though you don't trust him) I don't believe that it will actually do the harm it could do in theory. But you have to decide for yourself if you still have this kind of trust or not.

To make sure that you got fully rid of the product you should reset the system into a known good state - which usually means to install a backup of the system or to reinstall the system. The same is true for PC and phone. Note that in theory such product could nest deeply into your system so that a simple restore from backup will not work. It could also infect your router and from this reinfect your system. But again, this is unlikely if this is really a well-known and usually trusted vendor.

As for the sudden slowness you see: there is no generic explanation and solution for the behavior you describe. While there might be an explanation and solution for your specific case there is not enough known about your case and apart from that this is not a PC support site. If you feel that the problem is caused by the AV product please contact the vendor or look for solutions in his support forums.


Preventing a spoofing man in the middle attack? I was humming along with my usual routine of listening to old Defcon videos trying to understand some of the basics of what's going on in the IT Security world, when I came across one explaining man in the middle attacks.

So I got to thinking. Well, what could you really do with that? Then I thought of an odd man in the middle attack that I'm wondering, if it would work.

So we all know routers direct packets along on their way to wherever they're going. This is fine and dandy. Yet what if you set up something a little more evil. When a packet comes your way (destination of which is one of a pre-compiled list of sites), what if I pretend to be that destination? What if you say "Yes I'm paypal.com! Lets make a secure connection!". Then you make a secure connection with that thingy. After doing this, you could make a secure connection with PayPal, and do everything the user is doing, yet you grab all the information you want (i.e. how many smiley faces they are sending to their brother Steve).

The only problem I can think of running across is, if the packet decides to take a different path. I'm not sure about this, but you might be able to tell the other system that you're changing your blah blah blah, so it should connect to your real blah blah blah.

Is there anything out there to prevent this? I can't think of anything, and the idea of people being able to do this is slightly scary...

A router misbehaving and trying to act as a fake server with regards to the client, and a fake client with regards to the true server, forwarding data in both directions, is the exact definition of a man-in-the-middle attack. Apart from routers (which act at the IP level), classic practical methods for MitM include:

hijacking a HTTP proxy
subverting the DNS so that the client uses the wrong IP
running a rogue WiFi access point

(This list is in no way exhaustive.)

To defeat these attacks, we use server authentication which, in the case of SSL Web sites (like https://www.paypal.com) uses X.509 certificates. When the client (a Web browser) connects to the Paypal server, it explicitly requires a "secure connection" (because the URL begins by https://, not http://) and will reject the server unless the server uses a certificate which:

is issued by one of the root CA that the browser trusts a priori (the Verisign/Entrust/Thawte/whatever that were included by the browser vendor), and:
contains the expected server name in it (www.paypal.com, as specified in the URL).

On mismatch, the browser will warn the user in a spectacular way. The MitM will be successful only if one of the CA goofs up (i.e. the CA issues a certificate containing www.paypal.com to somebody who is not at all the owner of the paypal.com domain), or the user goofs up (by using a URL which says www.paypal.com.evilhacker.com, or by not paying heed to the scary warning displayed by his browser), or the user machine is already compromised (e.g. through some malware which installed a rogue root CA).

Generally speaking, SSL has been designed so that security is maintained independently of the transport mechanisms. SSL security does not rely on routers behaving "honestly". SSL assumes that routers are all hostile.


How can I prevent tracking by ETAGs? An ETAG is a HTTP header that is sent-behind-the-scenes between a web browser and an web server.  This value is intended to control how long a particular file is cached on the client side.

There is an interesting side effect to this technology; ETAGs are saved on a machine even if cookies are deleted.  Some people / software have exploited this fact to make an ETAG "act" like a cookie.

This means that simply deleting cookies isn't enough.  One has to delete the entire web cache as well. That is a painful process to go through every time I surf the net on my test machine.

Question

What is the most reliable way to prevent tracking that occurs by ETAG headers?

I don’t know of any great solutions.  I can suggest three possible defenses, though all of them have limitations:

Privoxy. Privoxy can block ETag headers.
In particular, you can use crunch-server-header or server-header-filter in your Privoxy configuration to block ETag: headers from the server.
Also, you can use crunch-client-header or client-header-filter in your Privoxy configuration to block If-None-Match: and If-Modified-Since: headers from the client.  However, I don’t know of any off-the-shelf formula you can just grab and use: you’d have to build your own Privoxy configuration yourself.

Your browser. If you use Firefox, you can configure Firefox to clear your cache each time you exit the browser.  This may be bad for performance.  Also, with this approach, ETags can still be used to track you within any one browser session, so it is not perfect, but it should clear any ETag cookie when you quit your browser.

RequestPolicy. If you use Firefox, you could use the RequestPolicy extension.  One writer has pointed out that RequestPolicy may help defend against ETag tracking.  Often, web sites track you by including resources from third-party advertisers or analytics providers.  RequestPolicy lets you control what third-party resources your browser will request, when visiting a web page, and thus can let you protect yourself against that kind of tracking: if your browser never loads the third-party advertiser’s resource, then the third-party advertiser doesn’t have a chance to track you (using an ETag or any other mechanism).  This defense is less than ideal, because it requires you to laboriously assemble your policy, and because web sites can still track you directly if they don’t rely upon any third-party resources.

Unfortunately, if you access the web through a transparent proxy, the presence of the proxy may complicate your attempts to avoid being tracked.


How is CSRF token verified? I would like to know how the CSRF tokens are verified on form submit?

Please tell me  whether the following is correct:

Server issues a random string which is set as the session cookie, and a value for the hidden field in the form.
On the form submit, the server checks the session cookie with the hidden field value for equality, if values are not equal it won't process the request.

Yes, this is one possible approach to defending against CSRF. It's called the double submit cookie pattern.

The synchronizer token pattern - the second token isn't stored in a cookie but server-side in the session - is a bit more common in practice though.


How did the FBI compromise Tor users? I read in this article that the FBI was able to crack the anonymity of Tor.

From what I heard and read, onion routing makes it almost impossible to de-anonymize a user.

The last time I heard anyone trying to crack Tor was the NSA and it did not succeed or at least they did not publicly advertise it (The article was 2 to 3 years old now and may not be that relevant anymore).

Do anyone have any insights on how the FBI might have done it?

The article you link says that the FBI obtained "the MAC address" for the user computers. MAC addresses are specific to each ethernet hardware, and they don't travel beyond the first hop -- meaning that they are visible to your home router, possibly the one provided by the ISP, but not beyond. If that specific piece of information is true, then this means that the FBI really deployed a piece of malware on the site, and the users simply got it on their computer.

After all, the FBI first seized the offending site and ran it, at which point they had full control over its contents. People using Tor to access a child pornography site are not necessarily smarter than average people, and they would intrinsically "trust" that site, making malware deployment possible, even easy.

Tor anonymity relies on the idea that potential attackers (the FBI in that case) cannot control sufficiently many nodes to make correlations possible. However, that "sufficiently many" is not that big a number; if one of your connections, even temporarily, goes through an "entry node" controlled by the attacker, and the same attacker can see what happens on the exit (and he can, if he actually hosts the target site), then correlation is relatively easy (through both timing of requests and size of packets, because encryption does not hide size). With control of the target site, it would be even possible to change the size of individual response packets to help correlation.

However, Tor does nothing against hostile code sent to the user and executed by the user, and if the MAC address was recovered then such code was involved.


Why shouldn't my client just send the user's username and password with every request? I have a PHP server and an Android/iOS client, and SSL is used for all communication.

The PHP server is a JSON API with 2 public functions (register, login) and many private functions (which require the user to be "logged in").

I have gone through a few iterations and this is the current method of becoming "logged in":

User POSTs a login request to the server with a username and password.
The server attempts to authenticate the username and password with what is stored in the database (password_hash() is used when storing the password, password_verify() is used when attempting to authenticate, input data is validated and sanitized etc).
If the username and password are authenticated, the user is supplied with a JWT which will expire after 1 minute.
The JWT contains: expiry time, username, and user type.

All private functions require a valid, non-expired JWT. 1 private function is available to request a new JWT. I prefer this way of maintaining the session because it provides a kind of heartbeat (the server knows within 1 minute of the client becoming inactive).

I implemented the system in this way so that the user only needs to send their username and password once, so that the server only needs to do 1 database lookup to authenticate the user at the start of their session.

My question is: is authenticating once and maintaining a session (whether I do it this way or another way) any more secure than sending the username and password with every request and authenticating each time?

If you prompt the user to newly enter a Username and Password every single time the application needs to make an API call, they're gonna have a bad time and stop using it. Especially if a situation arises where a single "action" from their perspective kicks off multiple API calls that would need authentication separately. That's just not workable. That isn't the only way that "

The alternative is having the user's Username and Password stored on their device so the application doesn't need to prompt in order to send the request. The user can't tell the difference between the application holding an arbitrary token that enables access compared to username + password that enables access, so that's good. Unfortunately, there are some flaws in that as well, and those flaws are more security-relevant.

First, unless your application does internal encryption the username and password end up effectively stored right next to each other in plaintext. Even if there is encryption, the encryption key pretty much has to be stored close to what it's encrypting which isn't really much better. I can't say with precision how much of a vulnerability this is, and a token is likely to be just as vulnerable, but an attacker getting hold of a single token is likely less damaging than one getting the full username + password.

Second is, as you are aware, tokens are expected to expire with relatively high frequency compared to usernames and passwords. From the way your question is worded, you seem to be considering username + password in every request as the "highest level" of tokens expiring quickly, but it's actually the opposite: with no token in between, username and password become the token and only expire when changed. That makes the application somewhat more vulnerable to replay attacks, and makes it much more inconvenient to the user if you ever implement controls to detect malicious behavior: with a token, you can expire the token immediately but a real user can provide username and password to get a new one while an attacker who obtained just the token is blocked. A user entering their credentials every now and then is pretty minor, but forcing random password resets is significantly more burdensome on and it leans a lot on a secure password reset function.

Last, the username and password would be transmitted a lot more frequently. Ideally the secure connection is perfect and that's not a problem, but in practice there are some vulnerabilities that are more likely to be exploitable. For example, the CRIME vulnerability exploited the size of messages sent to leak pieces of information but required a constant value exist across many messages. That exact vulnerability is probably patched, but similar ones could exist in the future and if your requests are a little leaky then always having the username and password in them lets an attack piece-together that information over a long time, compared to a token which is less impactful to leak as well as limiting the time that an attacker has to obtain it.

All of that might not add up to a large security compromise, but I wouldn't risk it.


Limit Packets Per Second Since last week I have been seeing something fishy and it seems to be worsening. I tried many firewalls and they seem to be useless. I blocked all unwanted ports and only few ports are open so I found that my VPS get frozen when Packets per second get's over 20k. I want to know if there is some way to limit pps on opened ports and reject all other connections to the port until the pps get lowered to 10k.

Maybe this has been discussed, or will be available in Google, but I am unable to find (if this type exits) and only I found is this:

iptables -I INPUT -p tcp --dport 1234 -m hashlimit --hashlimit-mode srcip,srcport --hashlimit-name HASHNAME --hashlimit-htable-max 5000 --hashlimit-htable-expire 10000 --hashlimit-above 5/sec -j DROP

But I don't know what this rule means.

You can limit connections by network blocks, e.g. choose a size such as a C class (256 IPs) and then limit each C class connecting to you to say 10 connection per block of IPs. Unless an attacker is on the same C class as you (unlikely) then you will be able to connect still. To do this use the "--connlimit-mask" option, explained in:

http://ipset.netfilter.org/iptables-extensions.man.html

An example to limit access to your SSH server port would be:

iptables -p tcp --syn --dport 22 \
-m connlimit \
--connlimit-above 10 \
--connlimit-mask 24 \
-j REJECT

So first we specify the protocol TCP, then SYN packets (connection initiation) and a destination port of 22. Then we use the connection limit module, limit it to 10 connections for each network block with a network mask of /24 (a C class with 256 IPs).


Iptables rules to prevent IP Spoofing We had following below iptables rules that exist in our web front-end boxes to prevent IP Spoofing:

    -A INPUT -s 255.0.0.0/8 -j LOG --log-prefix "Spoofed source IP"
    -A INPUT -s 255.0.0.0/8 -j DROP
    -A INPUT -s 0.0.0.0/8 -j LOG --log-prefix "Spoofed source IP"
    -A INPUT -s 0.0.0.0/8 -j DROP

We want to add below rules now to further harden IP Spoofing prevention

     -A INPUT -s 224.0.0.0/3 -j LOG --log-prefix "Spoofed source IP"
     -A INPUT -s 255.0.0.0/8 -j DROP
     -A INPUT –s 169.254.0.0/16 -j LOG --log-prefix "Spoofed source IP"
     -A INPUT -s 169.254.0.0/16 -j DROP
     -A INPUT –s 240.0.0.0/5 -j LOG --log-prefix "Spoofed source IP"
     -A INPUT -s 240.0.0.0/5 -j DROP

Do you suggest adding above rules in a production box running Apache httpd as a reverse proxy? This production box is behind a F5 load balancer.

Also, do we need to enable the below kernel parameters for the above rules to work effectively?

               net.ipv4.conf.all.rp_filter=1
               net.ipv4.conf.all.log_martians=1
               net.ipv4.conf.default.log_martians=1

iptables -N spoofing
iptables -I spoofing -j LOG --log-prefix "Spoofed source IP"
iptables -I spoofing -j DROP

iptables -A INPUT -s 255.0.0.0/8 -j spoofing
iptables -A INPUT -s 0.0.0.8/8 -j spoofing

This saves you duplicating the log and drop rules over and over and over again.

You can't stop bad guys from spoofing.  A spoof'ed ip can not perform a 3 way handshake as required by TCP, but UDP has no such restriction.  Also if the hacker spoofs your IP and sends it to google.com or etc they will attempt to connect to your IP thinking you tried to connect to them.

Some ISP are now restricting this kind of thing, but many still don't.


How TLS certificate chain is verified Assume the verification of a TLS certificate chain. Suppose the chain has certificates A-B-C-D where D is the root certificate and A is signed by B, B by C, C by D.

Suppose the intermediate certificate B is found to be already built into the browser. That is, A is checked, it found to be valid (and signed by B) and B is built into the browser.

(1) Does the verification of the chain end there or does it continue on until we get to D?

(2) When a server presents it's certificate chain to the browser, does it present the root certificate D as well or does in only present A-B-C?

(1) Does the verification of the chain end there or does it continue on until we get to D?

it depends on a certificate chaining engine (CCE) implementation. Different platforms have different implementations which may not support all recommended/mandatory validation logic described in RFC5280.

Certificate trust requires an end of chain point which is presented in a self-signed form (we call such certificate as Root CA certificate). Since certificate B is not self-signed (it is signed by C), the A-B-C-D chain is not trusted until C and D are fetched and validated. So, the answer to this question is: the chain continues validation to the root.

If we talk about Microsoft implementation (just an example which I'm familiar with), their CCE builds one or more chains (as much as possible) without performing immediate validation. They just fetch certificates and attempt to perform basic rules to bind each certificate at the correct place in the chain. When all chains are built, each of them are validated according to rules described in RFC5280. Once validated, there might be a case that there are multiple trusted and valid chains. CCE uses its own selection logic to select only one chain from a collection of chains.

When we talk about cetrtificate stores in browsers, they are used to:

establish a trust to a particular trusted root CA (Trusted Root CA store). These certificates MUST be presented in a self-signed form. Otherwise, they cannot be used as chain endpoint and the trust is not established (even though, the intermediate certificate is installed in the root store).
help CCE to quickly build the chain without having to download missing certificates from internet, because they are available locally. Some brwosers completely lack an ability to process Authority Information Access extension, which means that SSL client is able to fetch CA certificates only from two sources: SSL handshake, local certificate store.

  (2) When a server presents it's certificate chain to the browser, does it present the root certificate D as well or does in only present A-B-C?

it depends on a web server implementation. A reference from RFC 5246 §7.4.2:

  certificate_list
        This is a sequence (chain) of certificates.  The sender's
        certificate MUST come first in the list.  Each following
        certificate MUST directly certify the one preceding it.  Because
        certificate validation requires that root keys be distributed
        independently, the self-signed certificate that specifies the root
        certificate authority MAY be omitted from the chain, under the
        assumption that the remote end must already possess it in order to
        validate it in any case.

RFC suggests that root CA certificate MAY or MAY NOT be sent to client. As the result, when developing SSL client you should expect that root certificate may be shipped along the chain. Two major web servers: Apache and IIS by default DO NOT send root certificate during SSL handshake.


Building a web app with encrypted MySQL database entries? I have some experience in building PHP based websites with MySQL access, storing encrypted user details, but all other fields being plain text. My most recent project will require sensitive data to be stored in the database.

I want to set up a system where a user can access his own entries and see the plain text results, but even if he was able to access someone else's they would be encrypted, unintelligible strings.

I have an idea of how to accomplish this, but perhaps it's not optimal or there exist tools to do this already in a more efficient way.

1.) Store username as plain text, and password hashed with sha1() or better hashing algorithm plus random salt etc.

2.) Take the user's password (not the hashed one, but the one he typed in) and use it do define a key specific to that username and password, which will then be stored as a session variable. Since the key is never stored anywhere except in the user's head (in the form of him knowing his plain-text password, which will then be converted to a key somehow by mixing it with his username and some salt, hashing etc, as he inputs it to log-in) this should be a good solution right?

3.) Encrypt, or decrypt all of that user's data with that key.

In my opinion even if someone gained access to the database and saw a list of plain text usernames and encrypted passwords they couldn't figure out the specific key since it's not stored anywhere. Therefore even if access was gained, they couldn't decipher the content of the sensitive database fields. Of course I'm building in ways to stop them accessing the database anyway, but as a catch-all effort this seems like a good set of steps.

Could the experts please comment on this, and offer some advice? Thanks a lot.

I posted this in the programmers.SE forum and they advised me this was a better location for the question. More specifically why I shouldn't do this myself. If so then what alternatives are there?

What you are talking about is a derived key.  The technique you describe is frequently used for high security systems, though I would further recommend that you use the derived encrypt a data key.  This allows the data key to be stored with more than one derived key and limits the use of the derived key.  This allows for data sharing, keyrings and account recovery.  Also, keep in mind that the derived key itself is only as strong as the password, so salting and slow key derivation functions should still be used to ensure that password derived keys can't be formed for all the users passwords at once.

Derived keys tend to be weaker than truly random keys, so you want to encrypt the minimum amount possible with them.  If you encrypt only the user's data key with it, you can decrypt the user's data key and then store it in the session.  That truly random key can then be used for encrypting and decrypting the user's data.

A further enhancement is to associated keys with records and then encrypt that record key with the user key in order to give the user access.  If you use asymmetric cryptography here, it would be possible for a user to grant record level access to another user by encrypting the record key with the public key of the user they wish to share with and adding it to the other user's keyring.

Similarly, for account recovery, the user keys could be encrypted with a public recovery key.  The private key could be held offline or associated to an admin user (with similar derived key protection) and only used by customer service when necessary to restore an account.


Can I rely on the CSRF cookie to check if a user is authenticated on the client-side? I have a website that runs on example.com. The website makes AJAX calls to my backend API which sits at api.example.com.

I employ a double-submit verification strategy.

The backend has protected endpoints which check the JWT token with each request. The JWT token is stored in a httpOnly cookie. It also contains the CSRF token.

Alongside the JWT cookie I also send a CSRF cookie which is not httpOnly.
Each request that the client makes must contain the value of this cookie in a special header.

So far so good, but, I want to make sure that the client does everything in its power to prevent users from making pointless unauthenticated requests. So in my React app I have declared a few private routes which check if the user is logged in and if they are not, the user is redirected to the login page.

The way I check if a user is authenticated is by checking if they have the CSRF cookie. If they do, they are allowed to navigate to the protected page. All subsequent requests on this page are still verified on the backend for a JWT and CSRF token.

My question is, is this a valid way to check that the client is authenticated on the client-side?

Additionally, should I be setting the sameSite cookie option to True for both cookies?

EDIT

One thing I have just thought of is that it is probably better to create a simple endpoint on the backend that is used to check if the user is logged in. So instead of just checking the cookie, the client can submit a request to this endpoint and verify that the token in the cookie is still valid.

This is more a web application architecture question than a security one.

Isn't having a JWT token enough to consider the user logged from the client side perspective?

I assume the user authenticate before getting the token, presumably from the successful login response.

When the token expired return an unauthorized response, look for this response on every ajax response (https://github.com/axios/axios#interceptors) and redirect the user to the login page.


Can a website's privacy policy be made more effective by incorporating it into company bylaws? I'm concerned primarily about the US, but also UK and Germany.

Is there any way to give a privacy policy greater trust, and more effectiveness, by somehow binding it to a company's bylaws with the state?

The common way to ensure customers that you actually respect your own rules is to ask a third part to audit and certificate your business. If it is important for you, ISO provides a bunch of normative document that certification organization know. The best known is ISO 9001 for general Quality Management, and the IT counterpart is ISO 27001.

So my opinion is that the best proof you can provide to you customers is a ISO 9001 + ISO 27001 certification.


Beating CSRF using Tokens I am new to web programming. I read an article where they advised to use tokens as a hidden field in forms and match that token at the server end to detect non-legitimate requests. I am wondering what difference does it make, if an attacker uses an iframe to fetch a form,that form is going to have the token id generated at server and it should be matched.I went through article on owasp.org but it sounds too cryptic for me.

If the attacker embeds your form on his site, we're talking about a very different attack called clickjacking. A token doesn't help against clickjacking, you need different methods of protection (specifically the X-FRAME-OPTIONS header or JavaScript framebusters).

Cross-site request forgery means that the attacker creates his own form pointing to your site. Then the attacker tricks the victim (or the victim's browser) into submitting the form and taking actions on his behalf.

A token does help against CSRF, because the attacker doesn't know the token of the victim and hence cannot prepare a valid request. However, there are some limitations. If you use cookie-based protection, then an attacker might be able to set his own cookie with a known token. And cross-site scripting vulnerabilities generally break all CSRF protection.


How to send deauth packets from osx? aireplay-ng is not available for Mac OSX. How can I inject frames into the network? I am only concerned with sending deauth packets.

EDIT: Kismac2 is also no longer being maintained however the current build still works on OSX High Sierra

Kismac2 has a very large set of functions, including deauth.

https://github.com/IGRSoft/KisMac2/blob/master/README.md

Although kismac-ng (a previous incarnation) has been abandoned, kismac2 is now the tool of choice for most pentesters and wardrivers who need a quick overview of networks, and several attacks.


What are the risks of redirecting my email with Google Domains? I have bought a domain from Google Domains. One of the features they offer is to redirect all email sent to that domain to any other email address of my choice. Now I'm wondering; is it secure and private?

How secure is using this service? Can Google read the content of the incoming emails if they redirect them for me?
Is it safer to let another site handle the email address(es) instead? For example, ProtonMail offer the possibility to receive all email sent to a domain I own. How does this option compare to telling Google to redirect the emails to my ProtonEmail account?

If any email service is processing mail, then there is a possibility that they can "read" the emails. That goes for ProtonMail, too.

The only way to avoid the risks is to have end-to-end encryption of the email content. Email has never meant to be secure from the email handling infrastructure.


What to transfer? Password or its hash? Let's say in my database I store passwords hashed with salt with a fairly expensive hash (scrypt, 1000 rounds of SHA2, whatever).

Upon login, what should I transfer over the network and why? Password or its hash?

Is it possible to protect such login over an unencrypted channel like HTTP?

If you transfer the hash from the client, this affords no security benefit, and makes the hash pointless:
If a user can login by sending the hash to the server, then the hash is effectively the password.


Difference between Zeek (Bro) and Snort 3 I'm trying to find difference between Zeek and Snort 3. Сan anybody tell me what are the advantages of Zeek against Snort 3?

Snort is more a traditional IDS/IPS which does some deep packet inspection and then applies signatures on the traffic in order to detect (and maybe block) attacks.
Zeek does not claim to be an IDS: instead it claims to be a network monitor and traffic analyzer. From their own description:

Zeek is a passive, open-source network traffic analyzer. It is primarily a security monitor that inspects all traffic on a link in depth for signs of suspicious activity. More generally, however, Zeek supports a wide range of traffic analysis tasks even outside of the security domain, including performance measurements and helping with trouble-shooting.

As far as I know (i.e. what I got from discussions with others) Zeek is therefore more used to capture the details of the traffic and forward these to some analysis system. The analysis regarding attacks is primarily done outside of Zeek and the focus for Zeek is on collecting detailed information about the traffic.  Sometimes custom protocol dissectors are added which are specific for the protocols used in the environment. I think Bro/Zeek is for example used in Darktrace to get the traffic details.
Classical signature based IDS like Snort or Suricata are instead more used as actual IDS, i.e the focus is on matching specific attack signatures. For example Cisco provides its subscribers new signatures when new attacks emerge. But I also know several cases where Snort or Suricata are used to only collect information about the traffic and feed these traffic details into a larger system, similar to how Zeek is typically used.
In other words: there is overlapping functionality. But the primary goals of these tools are different and thus are also the use cases.


Windows Certificates - where is private key located? In Windows 10:
When I load a certficate into the "Current User" store, it puts a private key file here:
C:\Users\[userID-A]\AppData\Roaming\Microsoft\Crypto\RSA\S-1-5-21-xxx\pkfileqreflr8029r...

When I load a certficate into the "Local Machine" store using a different UserID-B, I don't see this path at all:
C:\Users\[userID-B]\AppData\Roaming\Microsoft\Crypto ...   there is no \Crypto folder created.
Does anyone know where the private key is stored when a pfx file is used to import a cert into the Local Machine store? Thanks.

The locations are listed in Microsoft Docs on Key Storage and Retrieval.
For Local system private the locations are:

The Microsoft legacy CryptoAPI CSPs store private keys in:
%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\S-1-5-18\
%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\DSS\S-1-5-18\

CNG stores private keys in:
%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\SystemKeys

In practice they are by default under C:\ProgramData\Microsoft\Crypto\ on Windows 10.


Is this social engineering on facebook? Today, I received a mail from fb saying that two of my friends have mentioned me in a comment. When I opened fb to see that comment, it was filled with random names (which obviously were their friends/friend-of-friends) and mine was one of them.

And the topic of the comment was an advertisement proclaiming a hack to reveal any fb user's username and password. It then gave a bunch of instructions asking you to visit the user's page, opening the browser web-console and pasting some code there. It claimed that doing so would reveal the said user's fb username and password (which is obviously absurd).

fb username of this topic poster was Beauty.20000. But whats going on here? Is this an attempt at social engineering (as I suspect) ?

Yes, this is known as "self-XSS" or "self cross-site scripting".

Some websites now show a warning in the console:

Any code you paste here can be executed on the current page. If you're logged into Facebook, whoever wrote the code that you paste has full control over the current page.


Two-way secure communication using two pairs of public/private keys? Let's say I want to create a protocol to securely communicate between two endpoints - each of the two endpoints know the other's public key and all data exchanged is encryted using one's public key and decrypted using the recipient's private key. My question is aside from man in the middle attack which can be avoid by using a PKI(?),  what other kinds of attack is this protocol vulnerable to? And how is it compared to SSL as we have removed the initial handshake step?

This protocol is vulnerable to a replay attack.
In common notation

A -> I_B: {m}_PK(B)
I_A -> B: {m}_PK(B)
I_A -> B: {m}_PK(B)

If m was a message saying loan me $10 and B was a little naive ...

This protocol is also vulnerable to message reordering attacks e.g.

A -> I_B: {m}_PK(B)
A -> I_B: {m'}_PK(B)
I_A -> B: {m'}_PK(B)
I_A -> B: {m}_PK(B)

If we assume RSA, then if there is no padding then such a protocol would be weak to homomorphic encryption attacks.

Various other attacks are obvious but uninteresting (such as denial-of-service by the intruder blocking all messages, dictionary attacks letting the attacker verify a guess at the message, dictionary attacks letting the attacker detect repeat messages, message truncation attacks etc.)


Flawed understanding of SQL Server Transparent Data Encryption (TDE) We host a database for one of our applications on Microsoft SQL Azure. One of our clients was dissatisfied with the fact that TDE is not supported on SQL Azure (and the database is otherwise not encrypted at rest). Their concerns were mostly along the following lines:

  Data-center employees that have access to the VMs also have access to
  the database. We should use TDE to make sure that they can't get
  access to customer data from our database.

My reasoning is that if a data-center employee has administrator login access to the VM that hosts the SQL Server then they automatically gain access to the keys used for TDE. Which defeats the purpose of TDE in that case. The only real benefit to TDE would be for securing backups of the database.

Am I wrong in thinking so?  And are there any alternatives to securing the whole database, relatively painlessly?

No, your understanding of TDE is not wrong.  A user with the appropriate permissions on the SQL Server instance can access the data in the database, and with SQL Azure, even if TDE were enabled, the DBAs in charge of the instance would certainly still have full access to the data.

What can you do?  Well, you can encrypt the data in the application before you ever send it to the database.  This creates a whole slew of additional constraints on how you query and use the data however, and is generally only appropriate in very limited use cases.

Ideally, you'd convince the client that this is an acceptable risk.  The cloud providers business model is built around protecting their clients' data, not stealing it.  It isn't in their best interest to abuse their position of trust in that way.

To me this sounds like its probably a search for a technical solution to a problem that doesn't need solving.   I understand the concern, but in my opinion, the concern is out of proportion to the risk.


Why should an IKE responder change the cookie secret 'frequently'? IKEv2 has the concept of a COOKIE mode, to attempt to prevent state exhaustion from floods of initiation requests from non-existent IP addresses:

  Two expected attacks against IKE are state and CPU exhaustion, where
     the target is flooded with session initiation requests from forged IP
     addresses.  These attacks can be made less effective if a responder
     uses minimal CPU and commits no state to an SA until it knows the
     initiator can receive packets at the address from which it claims to
     be sending them.

An initiator sends a request to a responder; the responder constructs a cookie using a secret the initiator doesn't have plus details from the request and sends it back to the initiator. The initiator then repeats the request but this time with the cookie attached, thereby proving that they can receive packets sent to the source IP address of request.

The RFC recommends how the cookie could be constructed:

  Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)

Where Ni, IPi and SPIi are non-secret values that uniquely define requests from an IP address.

The RFC goes on to say that

  The responder should change the value of <secret> frequently, especially if under attack.

Why does the RFC make this recommendation?

Strongswan implement this by limiting the number of uses of a secret to 10000. Windows embeds a time value with a resolution of 150 seconds (see para 28) into the cookie.

If the secret is never changed, then once an attacker has seen a response for a given source IP and request parameters, they can then spam the responder with requests alongside a correct cookie. So there is certainly a good reason to change it at some stage.

But (assuming a good hash function) the cookie doesn't leak useful information about the secret to the flooding attacker. So without changing the secret more often than, say, daily at most, this scheme seems to provide protection against the stated goal (state exhaustion from floods of requests from IP addresses outside of the attacker's control). An attacker needs to observe a response from the responder to a request from each IP address that they want to send requests from before the responder will maintain any state for that request.

So why "frequently"?

(A legitimate answer might be "why not?" - I'm just wondering if there's anything more to it.)

Suppose that the "secret" is kept unchanged for weeks. As an attacker, I could make many connections without IP spoofing, spread over several weeks. I would thus gather possibly millions of "valid cookie values", each for a given source IP address and associated parameters (the Ni, IPi and SPTi values from the RFC). This is the preparation step.

Then, when the attack should actually occur, I replay them all en masse, within a 5 minutes time frame, with the required IP spoofing so that the cookie values match, forcing the server to allocate resources for millions of clients. This will drown the server quite effectively.

By construction, this attack is limited to the number of valid cookies ("valid" in the sense of "will be accepted by the server at the time of attack") that the server could generate. Every change of secret invalidates old cookies. By changing the secret often, the maximum size of the set of currently valid cookie values is kept low, avoiding the attack described above.

Now, of course, claiming that the secret should be changed "more often" in case of attack is just a shamanistic dance to propitiate the Spirits of IT Sec. Similarly, when I see that a homemade construction of "hash the data with the secret appended" is described as "a good way", I cringe and growl and shed tears of blood. Haven't they heard of HMAC ? Do you want to follow cryptographic advice from people who have not heard of HMAC ?


Is it possible to give legal value to signed web services? The context is using digitally signed webservices (with XML-DSIG for example) for e-government interoperability between databases.

The idea is to give endorsement to both the data publisher and the data consumer: the data publisher receives signed requests, which ensure the consumer identity, the authenticity of the request, and forbid the repudiation. The same occurs with the response received by the data consumer.

The problem is: who is signing the webservice, and with which legal value? In my country, only "natural" persons are given legal value when digitally signing, and under the principle of being able to read the document before signing it. But obviously a "natural" person isn't able to process and sign every request, so this person has to delegate the signing to the server, with the risk of identity theft it implies.

In this context, do you think this digital signature may be allowed legal value? Do you think any government responsible will accept delegate his digital signature to a server? And the most important: which alternative scheme do you recommend?

We are working in this domain for some time. As you've already mentioned - there's a difference between the technical signature (so the systems/databases can rely the data integrity is ensured) and  legal value of data itself, where (according the legal framework) legally can sign only a 'natural' person.

Each state effectively 'validates' its own citizens and assures theirs identity (issuing their ID card, passport, authentication and signing certificates). There can be an application certificate issued, but they have no legal signing value. Most of the countries adopt this principle.

Often there's a mutual agreement between organizations to trust their signed data from the applications outside scope of the legal framework. I see many initiative to automate the signing (I'd support myself), but - as WoJ mentioned - the application cannot take own decisions and cannot assume any legal responsibility.

I've seen a system where the responsible person signs a batch (whole list of the document digests) without effectively having time to read all the documents. In this case a Hardware Security Module is used. Still - it is the person who legally takes responsibility so sign the documents.


Why use an authentication token instead of the username/password per request? The author of https://stackoverflow.com/a/477578/14731 recommends:

  DO NOT STORE THE PERSISTENT LOGIN COOKIE (TOKEN) IN YOUR DATABASE, ONLY A HASH OF IT! [...] use strong salted hashing (bcrypt / phpass) when storing persistent login tokens.

I was under the impression that login cookies served two purposes:

UX benefit: don't ask the user to login once per request
Performance benefit: don't need to run a slow algorithm (like bcrypt) per request

It seems the author is invalidating the second point, which makes me wonder: why bother with authentication tokens at all? Instead of mapping the username/password to a randomly-chosen authentication token, why not simply pass the username/password per request using a httpOnly, secure cookie?

Assuming we accept the author's recommendation and use bcrypt per request, what's the advantage of using an authentication token instead a username/password?

When you use an "authentication token", the simple presentation of that token by the client grants access (as long as the token is deemed valid by the server). If you store the tokens "as is" in your server's database, then an attacker who could get a glimpse at your database will immediately learn all the tokens, allowing him to send requests in the name of all users for whom a valid token still exists in the database. This is bad. Hence the recommendation of storing only a hash of the authentication token.

The advice about bcrypt for authentication tokens is misguided. Bcrypt, like all functions dedicated to password hashing, is meant to be used for passwords. Passwords are weak; they are vulnerable to dictionary attacks. To cope with their inherent weakness, the password hashing function must be salted (to prevent parallel attacks and precomputed tables) and must also be awfully slow (through a huge number if internal iterations). This makes password hashing functions expensive. So you don't want to use a password hashing function unless you need it, e.g. to hash a password.

An authentication token is not a password; it is a random value which was generated and remembered by a computer, without any human brain involved in the process. As such, if you generated the token properly (at least 128 bits, obtained from a cryptographically secure PRNG), then there is no need for salts or iterations; just use a plain hash function (even MD5 would be fine there). This will be more efficient.

As for using a random authentication token instead of login+password for each request, there are two main reasons for that:

Performance: as explained above, an authentication token can be verified safely with a simple hash, which will be vastly more efficient than a heavy bcrypt call. You want to keep your precious CPU cycles for when they are really useful, in particular when applying bcrypt to an actual human-managed password.
Client-side storage: the authentication token will be stored on the client as a cookie value. If the login and password are sent back with every request, then they are stored as a cookie on the client. People get nervous when their passwords are written to files -- and such storage is not equivalent (from a security point of view) to the storage of an authentication token, because human user are on the (bad) habit of reusing their passwords for multiple systems, whereas authentication tokens are inherently server-specific.


What would be required to monitor Amazon Alexa traffic? I had this interaction with a friend's robot today:

"Alexa, are you spying on me?"
"I only send audio data back to Amazon when I hear you say the wake word."

If I wanted to ensure that Amazon is indeed only exfiltrating recordings from the network /after/ saying the wake word, what would be required to do that?  I'm imagining something like having the router block the Alexa outbound traffic unless an additional device, say a raspberry pi, also detected the wake word and opened the gate.  (I imagine Alexa polls periodically just to make sure it's connected and would complain.)
You're welcome to provide a packet inspection/forensic solution, but I'm curious about third party work-arounds that actually forcefully prohibit communication.
I further understand there is another security issue, that Alexa could very well only send audio data back to Amazon when she hears the wake word, but /could be recording all speech all the time/, and just sends it back to Amazon in bursts when woken up and perfectly compliant with what she told me, and I don't think there's a way around that.

As you noticed, Alexa could record all the time and send it only after you say the wake word. You could notice it by larger upload size. But at the same time Alexa could analyse the recordings and only send interesting parts like when you mention the word "bomb" which reduces the upload size so you would only notice it if you look at the traffic in a very detailed way. You also cannot block it in a comfortable way because you would need to do a detailed analyses of the data before it is sent which most likely makes the use of Alexa meaningless because it is more work then doing the work Alexa should do yourself.

But you have 2 options:

Use a trusted client instead of the vendor provided (I don't know if one exists)
Use another trusted device that powers on Alexa when it hears the wake word and all the other time cuts the power line.


How can I prove that my software is secure for those who are interested to install it? I've written a password locker program for Microsoft Windows that encrypts its contents to the local machine. The only way to get the data out is with the encryption key the user knows.  It uses the existing APIs in the OS to do the encryption.

I think it is secure and haven't written any backdoors in it, but I'm not getting any traction in distributing it because people don't trust that such an application isn't backdoored or securely encrypted.

What can I do to properly assure potential users that software is safe to use?

Prove is a strong word, and to be honest, it isn't the word you're looking for.  What you really want is trust.   You want users (or potential users, in this case) to trust that your software is secure enough for them use to protect their most sensitive data.   There are several ways that you can do this.

Open source the software.   If users have the ability to review the source code, technical users are more likely to trust it, even if they never do review the source code, or in many cases are not even qualified to review the source code.
Get an independent opinion from a qualified third-party.  In other words, an audit that gives your software a clean bill of health.
Professional presentation.  If your software is on a website that looks like it was built by an amateur in his spare time, many people will ascibe to it that quality for all of its features, including security.  If it's presented professionally, and looks to be backed by someone professional, correctly or not, people will think more highly of it.  Such is psychology.

Ulimately, your biggest challenge is likely not in your offering itself, but in the competition.  There is a lot of password manager software out there.   Yours needs not only have to appear to be of high quality and secure, but at least as high quality and secure as theirs.


Do Veracrypt encrypted volumes have any kind of brute force protection? I have a 10mb encrypted volume which I made with Veracrypt and was planning to upload it to the internet. I have a pretty strong password but was worried about its protection against brute force attacks. After searching this SE it seems like a Veracrypt encrypted volume can be easily brute forced ref1, ref2. If that's the case then given enough resources we can crack any encrypted volume with any length of password (>100) in mere days with parallel brute-forcing instead of years.

Do Veracrypt encrypted volumes have any kind of brute force protection built into it? Didn't Veracrypt creators know about this issue? Is there any other strong encrypting system which has brute force protection?

Any encryption is vulnerable to brute force attack, for example AES-256 has 2^256 keys, and given enough hardware we can “easily” brute force it. The problem is that there’s not enough silicon on Earth to construct enough processors to do it before the heat death of the universe. The fact that encryption can be bruteforced doesn’t mean that this will happen in a reasonable amount of time, and we can thank probability theory for that;)

The weakest link is almost always not the key of the encryption algorithm, but the password from which the key is derived. Some passwords are more likely than others, and this allows dictionary attacks on passwords.

In this respect the VeraCrypt project does everything by the books: they are using PBKDF2 with strong hash algorithms and high iteration counts (this is somewhat controlled by the user). Using PBKDF2 with random salt prevents the attacker from using pre-made hash tables and forces them to calculate every key attempt specifically for your container. Having high iteration count makes every attempt take a significant time (milliseconds to seconds). Repeated hashing is inherently unparallelizable (single PBKDF2 operation is unparallelizable, the attacker can perform multiple simultaneous guesses of course), so custom hardware wouldn’t help much.

In these conditions the only feasible attack is dictionary-based, bruteforce would take too long. If your password is secure against dictionary attack - you can have high degree of certainty in the security of your data.

Relevant documentation: https://www.veracrypt.fr/en/Header%20Key%20Derivation.html