Third Party Risk Management: Validating responses from vendors?

I'm guessing "FS" is Financial Services. Although I don't have experience in that industry, I've worked with similar processes in other industries and can outline what I've seen, both from the companies that I've worked for as well as from the companies that use us as a vendor.

The first step is typically an internal assessment. You build a business case, identifying why you need a vendor. You'll identify one or more possible vendors as well. If you have the capability to build, a build-vs-buy decision may be part of this internal assessment as well. This is often based on publicly available information to narrow down the scope and determine which vendors to engage with. This would also look at the intended use of the product or service and what, if any, additional work is necessary.

If the internal assessment requires a further assessment from a quality perspective (meaning more than just engaging with the vendor's sales teams to negotiate a contract), the next step would be a standard questionnaire. Many of the questions have overlap with various standards like ISO27001, SOC2, etc. If the organization has such a certification, I typically expect to see the answer indicating that the question is addressed by the certification report (and if they are really nice, citing a specific section or sections that I could read). If they do not have an appropriate certification that covers the case, then I would expect a specific answer to the question.

Based on the risks identified in the internal assessment and the answers to the questionnaire in the second step (which may include internal certifications), the third step would be an audit. This typically happens if the vendor doesn't have the relevant certifications. Except for the highest risk systems, a questionnaire plus relevant certification almost always eliminates the need for an audit.

The differences in what you propose and what I've often seen is that Tier 1 is something that doesn't require significant assessment or certification - the lowest criticality and risk vendors. Tier 2 receives a questionnaire, and they would be expected to produce relevant certification reports or undergo an assessment. Tier 3 would undergo an assessment, either due to lack of certification, questions raised by the certification report, or the level of risk identified in the initial vendor assessment. I'd point out that assessments may be done virtually, such as over Microsoft Teams, WebEx, or some other conferencing application.

The biggest differentiation is a risk. It's up to you to define what you consider to be your risks, though, and how much tolerance you have for different kinds of risk. Things like the cost of the product or service, the impact of not having access to the product or service, how integrated the product or service is to your core business are all some examples of things that you would have to consider. I'm not sure that anyone here could tell you what is most concerning to you other than you.

Just like we can't tell you how to perform a risk assessment, I'm not sure that we can tell you what evidence to collect if you were to perform your own assessment. As someone who has performed vendor assessments, I usually leave it up to the vendor to provide a description of their process, ideally before the assessment so I have time to review it. Then, at the assessment, I want to see how many times the process has been executed and a sampling of evidence from it. I leave the generation and demonstration of evidence up to the organization being assessed since it's their process and they know best how to demonstrate it.


I can see three main benefits.

Reduce the amount of passwords users have to remember. Users are encouraged to use vastly different passwords for different sites. Managing that many different passwords can be problematic. Obviously this isn't an issue if the user uses a password manager tool but let's be realistic, how many users can you expect to do that? A SSO solution can greatly reduce the number of passwords a user has to remember, which might encourage the user to choose a much stronger password.
Provides convenience to the users. A SSO solution literally means the user has to sign on just one single time to access multiple services. This is a huge timesaver especially if a company provides multiple services. A good example of this would be Google. While this might not strictly be accurate, I have a feeling that by reducing the number of times a user has to enter his credentials, the risk of an attacker intercepting the credentials through something like a keylogger will be reduced.
Reduce the headache of assisting users with password recovery. Imagine a company running ten different services. A SSO solution can greatly reduce the amount of helpdesk manpower needed as users only need to recover a single account. Whilst not a security concern, this is a very tangible benefit to companies.

Of course, a SSO solution concentrates a lot of power on the authentication solution. One should probably spend a lot more time and effort securing that single point of failure.


Are there actions taken against websites that deliver malware?

Okay, personal anecdote time.

I'm a sysadmin in real life, working for an ISP that primarily caters to small to medium businesses.

One of our larger customers operates, among other things, an exceptionally cheap and completely automated shared webhosting service. You sign up, pay a couple of bucks via credit card, and plonk your site down. No human interaction required of any sort.

As the AS that controls their IP block, we used to get phishing site complaints regarding that server like clockwork. We immediately forward those to the NOC of the company, who then investigate and delete the site... But by the time that's done the phishing site is already being hosted somewhere else entirely.

The credit card numbers used to pay usually turn out to be stolen (of course) and the registration request rarely comes from the same IP address more than once.

So what do you propose should be done about this?
Laws?

Whose laws?

The law of the country the server is in? Neither us (the ISP) or the company that runs the webhosting service is doing anything wrong. We're providing a perfectly legitimate service and respond as fast as reasonable when someone abuses said service for criminal purposes. I hate phishing and scammers as much as the next sysadmin who's had to deal with one dozen spambots too many, but we're already doing all we can and passing laws won't really change that.
The law of the country the scammer is in? Chances are, that country already has laws that deal with this. The only problem is, which country? Like I said, the origin IP is rarely the same twice and likely a proxy running on another compromised host, most likely someone's bot-infected desktop computer. ISPs don't exactly keep logs of every connection going in or out of all systems in their IP range, so even if we could get everyone's cooperation by the time we'd start looking the trail has gone cold.

You're also laboring under the mistaken impression that it's single site or easily isolated group of culprits. It isn't; between the myriad cheap registrars and webhosting services -- both of which are ultimately good things -- it's more like a crazy multiplayer game of Whack-A-Mole.

Terrestrial law enforcement can sometimes catch a break, but they do that by following the money, not the IP traffic.


Wi-Fi Protected Setup PIN method EAP Messages

When the enrollee sends proof of knowledge of the PIN, then the registrar can be assured that it is registering with the enrollee it expects. It works as a form of dual authentication.

Imagine a malicious, rogue WiFi AP that is programmed to accept any PIN, and therefore send 'confirmation messages' to any supplied input. An unsuspecting user could be connecting to the malicious WiFi, thinking they are connecting to their trusted network. By proving that it knows the PIN, the AP shows that it is the expected AP.


Why doesn't XSS execute when bypassing HTML encoding?

The developer console and the "inspect element" functionality of the browser is not a good way to check for XSS. This will show unencoded HTML elements, even though they are really properly encoded:

When pressing F2 or selecting "Edit as HTML", it properly shows the encoded characters:


How many ways are out there to know IP of client from website?

You assume the website identified the country via your IP address. How sure are you that this is in fact the case?

Modern browsers have a geolocation API which is accessible to javascript if you opt in (e.g. you should get a warning message when javascript wants access to your location).

Determining the geolocation can be done via IP address, but might also be done via wifi signal, mobile signal or gps signal if available. It's possible that your browser is leaking your geolocation not via IP address, but via one of the other venues, especially if you're browsing from a smartphone.


Is this Wikipedia article about SCRAM wrong?

The reason SCRAM prevents pass the hash is that the factors of the hash change due to the challenge.
(the counter should be a nonce thereby making it trivial for the real secret holder to calculate a new hash but hard for an attacker to calculate a new hash.)
Repeating the hash (as a Pass-The_hash attack does) should have an extremely small time window / be impossible to do silently. If the attacker has compromised the server all bets are off, regarding security (they have won by that point).
So the Server validates the authenticity of the connection/user by sending a nonce & Iteration count to the client. client uses this to calculate a hash response with the known and unknown elements (password hash) resulting in a once valid hash that the server validates by comparing it with the values it knows (hash of the password and the nonce / iterator).
You could  employ another level of hashing. this would ensure that just having the key as stored on disk is not enough to calculate the hash, but since someone probably also has the way you hash it again at that point it is a small difference.
Basically it all boils down to what threats are you trying to protect against, at what cost.


Which is better for SSL: TLS_EDH or TLS_SRP?

For web applications I'd go with ECDHE_RSA as preferred exchange with DHE_RSA as fallback.

ECDHE is forward secure, efficient, and gives you a high confidentiality level (128 bit using P-256). DHE is slower and has a lower security, but some browsers (such as Opera) don't support ECC.

I'd still use RSA for authentication. The security level required for authentication is lower, 1024 bit RSA is good enough when used together with ECDHE. You might want to increase it a bit beyond 1024, but that's mostly about PR, and not about actual security.

With such suites you use PKI with RSA to ensure you're talking to the right server preventing MitM, and (EC)DH for the key exchange, giving you forward secrecy.


Odd user registered and strange behavior. Is it sinister?

There are are two possible explanations that are very likely:

It might just be a very simple botnet client that uses a hardcoded string as username. There is a number of press reports saying that botnets owner offer there services to third parties. So while creating a botnet requires a lot of knowledge, the person using the botnet might not have much experience.
Someone might try to discredit a person with that name.

PS: Please do not post personal details about people using that username as nickname as it is quite unlikely, that they are responsible.


WDigest isn't a setting which disables Mimikatz, it's a form of encryption supported by Windows, which when enabled, allows Mimikatz to very easily dump plaintext passwords.

Disabling WDigest removes that one type of credential from memory, but a user with Administrator-level privileges can still dump other forms of interesting credentials. Mimikatz has plenty of additional capabilities which don't rely on WDigest!

So what you're really asking looks like a meta-question: How do I stop unwanted software running on my computers?

And in short, the answer is to either enable security features available to you:

Application whitelisting (AppLocker)
Antivirus software which detects potentially unwanted applications
Device hardening (particularly BitLocker (to prevent access to offline file systems) and if you can use Windows 10, Credential Guard)
Reduction in user privileges (don't let users be Admins)

Or potentially require use of Windows 10 S Mode or a device which can only run Store-derived software (and lock the selection down).

Preventing any kind of unwanted software (like malware) requires a holistic approach.


Can an android phone harm windows network?

Yes, any device that allows you access to a Windows network can be used to compromise that network. It doesn't matter that an android phone can't run exe files. I can grab tokens, attack files, databases...etc

And similar to @iismathwizard, I wouldn't expect to ever use cmd.exe on any device I was using to attack a Windows network. I may run the cmd.exe on a compromised Windows box, but to do that I'd have already connected to that box, and I can do that from any device I like with RDP/SSH/telnet/whatever


What is the difference between a digital signature and whole message encryption?

You have got that wrong, at least the encryption.

Asymmetric Encryption is done using public key of the receiver. Therefore it provides Secrecy (nobody without private key can not read the message). But it does not provide Integrity -- anyone can encrypt any message and send it to you with your public key.

Wikipedia is a good friend:

Digital signature works the other way round (as you describe). It does not have to be a hash. It provides Integrity itself, but also Authentication (you know who was the author of the signature -- you are the only one with that private key).


Whether it is an HDD or SSD, FDE will not write unencrypted data to the drive.

However on an SSD, there are no guaranty that data that existed before the FDE install are securely erased. (unless you are destroying the drive)


API credentials visible when creating Github pages website?

GitHub Pages is designed for hosting public websites, and it's great at doing that.  But as soon as you want to start keeping certain things private, it falls apart as an option pretty quickly.  Even if you have a private repo, GitHub will still serve all the files to the public - no authentication needed.

For this sort of situation, you want to use something other than GitHub Pages.  Which service specifically is not in scope here, but any hosting service that gives you a bit more control will work; you'll just need to run the Jekyll build process yourself and then publish the resulting HTML to your host.


Can I send/receive HTTP requests/responses with a subdomain on a crossdomain.xml file?

Yes , you can by using flash .

I did that before Leak the content of page by using misconfiguration crossdomian.xml file

Here is a useful reference that I used  Exploiting misconfigured crossdomain.xml files


How do companies deal with storing their source code on GitHub from a data-loss risk management point-of-view?

Contracts

The artist was presumably using Google's free services. The terms and conditions of such services tend to boil down to "we own everything, you have no rights" (disclaimer: I don't know the exact terms for the artist).

When companies pay serious money for an enterprise cloud platform, they have a contract that is much more in their favour. There is still a risk the provider could mess up, but this particular scenario could not happen.

Some other approaches are multi-provider redundancy and offline backups. Multi-provider does seem a good solution - although I've not seen it done in practice. Offline backups are problematic because of the high bandwidth needed to perform a backup.


Single randomly generated passphrase for both identity and authentication

The risks would include the one you mentioned:

  the attacker might incidentally happen upon another user’s passphrase
  while they’re trying to brute-force the first user’s passphrase,
  gaining access to the other user

For each user that is added to your service, the attacker gets a "free" guess during their attack. In your scenario of an attacker only going for a single user then this doesn't matter - but in the case where an attacker just needs access to one account, every password guess they try is automatically tested against each user account. This works in both an online and offline scenario (the latter might be possible if an attacker gets access to any password hashes that are stored - it's not clear if you're using these or not).

Another drawbacks is that automatic lockout or request throttling of repeated guesses against a particular user is not possible. This is the primary mitigation against password guessing attacks.

  if there are a quintillion user accounts, then it’s going to be easier
  incidentally getting someone’s account by brute-forcing. I don’t know
  how to calculate this, though.

Quintillion = 1,000,000,000,000,000,000
(World population 7,400,000,000)

Number of permutations = 2000^5 = 32,000,000,000,000,000

Chances that a guessed password (if the wordlist and method is known)
matches an existing one of the quintillion accounts = 3.2%

Chances if everyone in the world has one account =
2000^5 / 7,400,000,000 = ~1 in 4.3 million

In order to make these calculations meaningful you would need to know the approximate size of your user base. I doubt it will be as high as in the examples above, but with a quintillion an attacker only needs 32 guesses on average.


In the article they mention "TCP DDoS attacks", but the summary also says (emphasis mine):

  There was a considerable drop in the share of attacks over TCP (down to 18.2% from 26.6%) and ICPM (down to 7.3% from 8.2%). This caused a rise in the percentage of SYN floods and attacks over UDP and HTTP.

DDoS attacks on L4 (TCP SYN flood) is one type of an attack using TCP, but others can involve the application layer (L7). The authors mention HTTP as a special case, but one could also flood SSH or mail services with (small) requests that require more processing from the server side. These are services that run over TCP.


How to configure Browser to detect revoked certificates?

The only solution I was able to find is to use either Firefox or Internet Explorer, and enable hard-fail.

For Firefox:

Go to Options -> Advanced -> Certificates-> Validation
Check the box for "When an OCSP server connection fails, treat the certificate as invalid"

For Internet Explorer:

Can only be enabled in registry using FEATURE_WARN_ON_SEC_CERT_REV_FAILED. Blog post with reg file is here.

For Chrome:

Not possible to enable hard-fail

For Opera:

I don't know.

Notice that hard-fail has disadvantages. So don't enable it for friends/families which would get confused by the possible false positives.


What security measures does Chrome have in place to sandbox different user accounts?

It is not a true sandbox. It is more a way to keep several "profiles" in a way similar to what Mozilla/Firefox have always done: basically, each such "user" will have his own set of cookies and browsing history, but, at the OS level, there is just one Chrome and one user account. The normal Chrome "sandboxing" is active in the following sense: code within one page shall not escape the browser and mess with the user's files (or, for that matter, with other pages or tabs). However, if malicious code does succeed in escaping that sandbox, then nothing will prevent it from altering the profiles of all "Chrome users" because the protection at that level is from the OS, and the OS is oblivious to this separation into multiple "Chrome users".

Chrome has long resisted adding such a feature, claiming that it was better to use several OS-level accounts. They were theoretically right, but it seems that market pressure trumps theory every time; and then they yielded.


Assuming no MITM, is Gmail communication 100% secure and private?

Can things like the email Subject, the Recipient list, send/receive dates, etc be read by any 3rd party along the way?

Nope, unless you have been coerced to install some 3rd party cert on your computer. Some companies don't allow you to use the Internet unless you whitelist one of their certificates (and all https traffic is decrypted-reencrypted and sent along). In such a case, they can read everything you can (and taint the data too).

Another  thing that is possible is that you have added a malicious cert to your exceptions list without knowing what was going on. This happens -- user visits website, user gets ssl error, user adds exception. If that cert was a * cert or something like that1, then you're in trouble. Of course, you can easily check this in your browser certificate list.

However, since you've explicitly mentioned that your certificate list is pristine and there is no MITM going on, both of the above are ruled out.

Unless, of course, Google really is working with PRISM ;-)

1. I'm not entirely sure if browsers still accept * certs (CAs don't hand them out though). Firefox still seems to allow them. Either way, a similar attack can easily be done wth multiple-domain certificates: I can use an unsigned cert on manish.com that works for manish.com,*.google.com. Any visitor who whitelists my cert will be MITM-able.


What prevents a coder from brute forcing a wifi?

What makes WiFi encryption harder to brute force?

First, a strong password, preferably not set to the router default. The best password is set using a cryptographically secure random number generator (CSRNG), to the full 63 ASCII or 64 Hex chars. You can also use WPA-802.1X mode, however, this requires a Authentication server, and therefore is generally used for large networks.

However, a password built from five and more words would be far easier to remember, without significantly compromising the security of the key.

Another issue is WiFi Protected Setup, specifically, the PIN method significantly reduces the entropy for an attacker. The PIN is a 8 digit number checked in two chunks. This reduces the entropy from around 50 bits (5 word password) to less than 15 bits (2 times a 4 digit PIN), a factor of more than 34 billion. Turn that off, and you'll be relatively safe.


Why does Spring Security unset and set the same Cookie in one Request?

It looks like it's just a bug.
By looking at the history of the function onAuthentication, we can see that the first implementation only had the line:
this.csrfTokenRepository.saveToken(null, request, response);

Then, it was refactored by adding:
CsrfToken newToken = this.csrfTokenRepository.generateToken(request);
this.csrfTokenRepository.saveToken(newToken, request, response);

The first line with saveToken(null, ...) was never removed, despite serving no purpose.
In a comment, AlphaD pointed to a comment on a github issue explaining why the first line was kept:

it is first invalidating the cookie and then setting the cookie. That is expected if you log out and then try and use a token

Which should not be needed because the second Set-Cookie: should overwrite the previous cookie, thus invalidating it. In fact, this "obvious" behavior is not specified, so browsers are also free to discard the second declaration of a cookie with a conflicting name, which would break the expected behavior by the Spring developers.
Indeed, RFC6265 asks not ot use to Set-Cookie: with the same cookie-name (here XSRF-TOKEN), so this behavior is a pattern that is explicitly discouraged:

Servers SHOULD NOT include more than one Set-Cookie header field in
the same response with the same cookie-name.  (See Section 5.2 for
how user agents handle this case.)

Since this pattern should not happen and the RFC does not provide further recommendations, browsers are free to interpret it how they wish. Compatibility breaks with some browsers could happen at any time if they update their algorithm.


use namespace and cgroups or seccomp to implement online judge?

Comparison between namespace/cgroup with seccomp is not a good idea. These are intended for different purpose as you explained. Basically you should apply a combination of these, that is

Filter all critical system calls with seccomp
Isolate you service from accessing other process resource using namespace
Limit the resource usage (cpu, memory, core etc) using cgroup


Is there any way to crack a Bitlocker drive?

Unlikely. It's AES-CBC-128, so there's no chance of you cracking the key.

There are a few tools (e.g. Volatility, or Elcomsoft's forensics suite) that can recover the master key from a system memory dump, but that only works if the drive is already mounted and unlocked.


The Sophos seems to imply that this a a browser based attack and that you're infected by only visiting the site.

No, it doesn't. To cite from the site:

  ... These days, a lot of ransomware arrives in JavaScript attachments.
  ... The JavaScript doesn’t download the ransomware, it is the ransomware.
  ... On Windows, JavaScript outside your browser runs in the Windows Script Host (WSH)

Nothing in this article suggests that this is a browser based attack. In contrary, it explicitly says that the script needs to run outside the browser to have the appropriate permissions.

  ... can't find any practical examples of how this might be achieved

There are enough examples for using WSH (Windows Scripting Host) from a Javascript running outside the browser. For a specific case of how this is used in malware see for example Ransomware in your inbox: the rise of malicious JavaScript attachments. And with the help of WSH the attacker gets access to lots of functionality, including reading and modifying files.


PKI certificate validation graphs, trees and cross signing

AKI :

Authority Key identifier which is one of the certificate extension in PKI , through which we can identify the CA public key hash. It can be 160bit hash or 60 bit hash depends upon the CA who signs the certificate.

Cross - signing :

When cross-signing is implemented, the certificates are logically chained to the trusted

root CA of the organization that is evaluating the presented certificate.


How to secure a modem/ wifi router without login?

There is actually two different issues in your question:

ISP provided modem/router with no password,
Customer's page on ISP's website use the source IP as sole authentication.

ISP provided modem/router with no password

You have two possibilities, depending whether you opt to keep the ISP box or replace it altogether.

Solution 1: isolate the ISP box

Consider the modem/router as untrusted, part of ISP's network and not your own, and assume this choice. This is the choice I recommend since it fully complies with any ISP End-User Licence Agreement (EULA) and ensure you can benefit from any of their service or service upgrades now and in the future.

Moreover, it provides a good abstraction layer so changing of ISP or technology (ADSL, cable, fiber) is as simple as replacing the ISP box and affecting it the right IP, with strictly no impact on your own network especially if you do not rely on ISP's DNS servers.

To achive this you may want to take the following actions:

Disable ISP box's WiFi, and use a WiFi router of your own instead if you need WiFi capabilities,
Put a device with firewall capabilities (it can be the WiFi router mentioned above, and old computer, etc.) between your wired network and the ISP box with such kind of policy:

By default all communication between ISP's box IP and your LAN is blocked in every direction (the ISP box has no reason to contact your LAN's computers, and your LAN's computers while they go through the ISP box to access the Internet have usually no reason to contact the box itself),
One exception to the rule above: a lot of ISP's provide a DNS server in their box, unless you are using an alternative DNS server like OpenDNS or Google Public DNS (or your own!) you may still want to allow your LAN computers to contact the ISP box on the domain (53 tcp/udp) port,
When needed and only when needed, you can open an access from one of your LAN's computer to the ISP box HTTP (80 tcp) port (for instance) to access the administration interface. Do not forget to disable this access once your are done.

This will basically isolate the ISP box and relegate it to the role of a simple modem. In case you need some more features from your ISP box (television for instance), you can enable the access from the appropriate LAN devices to the ISP box on selected ports (you should find information on which ports to enable on Internet forums). Just be sure to keep administration ports closed by default (these are usually HTTP-80, HTTPS-443 and telnet-23, don't forget this one!) because these are the dangerous ones.

Solution 2: replace the ISP box by an ADSL modem or a router in bridge mode

The good thing is that this solution will give you maximum control over your Internet connection:

You will be able to handle yourself the QoS of your Internet connection, mitigating bandwidth consuming uploads impact over downloads,
I've read that ISP use the VPI/VCI parameters to route flows to different networks in their infrastructure (Internet access, phone line VoIP, television video streaming, possibility maintenance stuff, etc.). From a black hat perspective, having the possibility to manually set the VPI/VCI parameters of your modem allows you to explore ISP's network parts not normally accessible (and probably less secured) if you were using the genuine ISP's box.

I say the latter not to encourage you to do illegal stuff, but to make you understand why some ISP impose the use of their own box to their users and forbid custom firmwares. The attitude of ISP regarding this point varies a lot:

Some ISP's let the user fully free of their action  and officially allow user provided material to be connected to their network. They just announce that they provide support only for their own box, for other devices they provide generic ADSL parameters to use and it's up to the end-user to configure everything by himself. This was common in the pre "triple play" era, but nowadays it is sadly (but obviously?) not the way followed by the major ISP's.
Some ISP officially impose the use of their own boxes, but do not technically restrict anything. You can find the parameters to use for your modem on Internet forums, and it will work. Be conscious, though, that your modem will only provide you Internet access, all other services usually provided by your triple or quadruple play ISP box (phone, television) will not be available with your modem.
Some ISP strongly impose the use of their own boxes:

First they filter incoming connection request's MAC address and reject the connection if the device MAC does not correspond to the MAC allocated to the subscriber (a common symptom of this is that the box from one subscriber is not be able to connect at another subscriber's home).
Then from time to time they scan currently connected devices to detect non complying devices (I suppose such scanning can be easily merged in a script checking if your box firmware is up-to-date, except that it will not fail silently if it cannot connect to your box).

If you are detected as having maliciously bypassed the MAC check to connect a non compliant device to your ISP network, your ISP will consider this as a violation of the EULA and will be free to put an immediate term to your subscription (but you should not go in jail for this... unless it turns out that they also discover that you were wandering in their internal VoIP infrastructure following the black hat point above, if so be ready for some trouble...).

Customer's page on ISP's website use the source IP as sole authentication

Funnily enough, the security of home Internet access was one of my assignments in my last years study, and I saw with my own eyes such an awful practice.

Once someone gets access to your WiFi (if it is a stranger having no access to your home, but someone inside your home can do this from your LAN too), he gains access to the detailed phone bill showing every number you called, when and how long, access to the email box, plus any other service the ISP may provide (for instance some offer a web access to your phone voicemail) with the possibility to activate disabled ones... Well, huge security fail, fortunately this ISP eventually changed this to go on a more traditional and secure authentication system (it seems in your case this was optional, in the case I analysed it was not...).


Try:

$ cat /var/log/authd.log

This should show up events associated with user logins.


Can you steal session cookie with BREACH attack?

So BREACH is an attack specifically against response bodies, not headers.  Since cookies are sent as headers, they aren't susceptible to the technique described by BREACH, but have been vulnerable to other compression side-channel attacks such as CRIME.

What they mean by:

  (2) Reflect user-input in HTTP response bodies, AND (3) Reflect a secret (such as a CSRF token) in HTTP response bodies.

Is that (2) the attacker must be able to submit user input that he controls that is then added to the response body in such a way that he can submit guesses as to what the secret is, and (3) the application must also contain the secret he's guessing in the response body.

What this does is it creates an oracle.  Because it's attack on compression, he's submiting guesses for the first part of the secret, and when his guess is correct, it will cause the response body to be slightly shorter, because the duplication between his guess and the real secret will be eliminated by the commpression algorithm.  So, in simplictic terms, he keeps guessing a character at a time until he gets the correct next character, and the response body becomes a byte shorter.  Then, he moves to the next character and repeats the process until he knows the full secret.


Security tokens for external exposure: UUID or HMAC/JWT/hash?

I see a few concerns with what you've described:

Depending on how you generate the UUIDs, they may not be all that unpredictable -- they're not cryptographically strong tokens.
You do not describe a "purpose" in your security_tokens table, which might (depending on your code) allow someone to use a token for a different purpose than was intended.
Your system requires a lot of database traffic -- this might or might not be a problem, depending on the amount of traffic you anticipate receiving.

An alternative solution would be to use (for example) JWT and include in the signed data:

The user ID for which it is valid.
The purpose for which it is valid.

JWT itself provides the functionality for managing expirations.  Note that this does generate tokens that can be 'double spent', but if they are for validating emails or unsubscribing, that is not a problem.  (Is validating the same email twice a concern?)

For these tokens, all you need is a secret stored on the application server, and it incurs no additional database writes to either generate or spend the tokens.  (Which, again, is an issue of scaling, so may or may not apply to your application.)


Link Layer authenticated encryption vs authentication

I can think of a few benefits of authenticated encryption at the link layer over pure authenticity:

Enforces confidentiality on any traffic you might have forgotten to use application-level crypto on, e.g. database connections.
An additional level of hardening against replay attacks (harder to select target packets)
Hides sensitive information in higher-level protocols, such as sequence numbers in TCP.
Helps hide network topology when enabled network-wide, as IP addresses are hidden.

Keep in mind that these are rather tenuous though, and application-layer encryption should be sufficient when you've got link-layer authenticity enabled.


How to safely create a "honeypot (linux) user"

Allowing execution of an unknown source is not a good idea even if the user has minimal privileges.

Things that can be done by attackers:

The attacker can execute code on your hardware, and may use 100% CPU for mining cryptocurrencies for example.
The attacker may eventually have the opportunity to use a privilege escalation such as dirty-cow.
The attacker may find a suid file that was badly designed for privilege escalation.

There are opensource projects on GitHub that emulate a ssh session, and you can be in full control of the session: https://github.com/micheloosterhof/cowrie/blob/master/README.md


Are automated steganalysis tools commonly used in malware analysis?

Generally malware analysis and steganalysis are orthoginal to each other.

Malware analysis deals with malicious code.

Steganalysis deals with hidden messages.

Yes the hidden message could be malware but it really doesn't matter, it's just a hidden message until it's extracted. For it to run automatically as malware, some other code (malware) would have to do the extraction.

Generally the two don't cross paths but in the rare case that they do, you have malware first to point to the Steg and the malware defines the extraction. No need for a Steg tool.


How should web app developers defend against JSON hijacking?

The first defence is to stick to the specification by using valid JSON which requires an object as top level entity. All known attacks are based on the fact that if the top level object is an array, the response is valid Java Script code that can be parsed using a <script> tag.

  If the JSON response contains any confidential/non-public data, only serve the response if the request is authenticated (e.g., comes with cookies that indicate an authenticated session).

That's the pre requisite for the attack, not a mitigation. If the browser has a cookie for site A, it will include it in all requests to site A. This is true even if the request was triggered by a <script> tag on site B.

  If the JSON data contains anything confidential or non-public, host it at a secret unguessable URL (e.g., a URL containing a 128-bit crypto-quality random number), and only share this secret URL with users/clients authorized to see the data.

URLs are not considered a security feature. All the common search engines have browser addons/toolbars that report any visited URL back to the search engine vendor. While they might only report URLs that are explicitly visited, I wouldn't risk this for JSON URLS either.

  Have the client send requests for JSON data as a POST (not a GET), and have the server ignore GET requests for JSON data.

This will prevent the <script> include.

  Put while(1); at the start of the JSON response, and have the client strip it off before parsing the JSON.

I suggest a modified version of this approach: Add </* at the beginning. while(1) is problematic for two reasons: First it is likely to trigger  maleware scanner (on clients, proxies and search engine). Second it can be used for DoS attacks against the CPU of web surfers. Those attacks obviously originate from your server .


I work as a security consultant for SAML 2.0 implementations on a daily basis, mainly for business scenarios. Said that, most security teams are OK using SHA-1 for the same reasons described in this post (that was already mentioned in a comment).

On the other hand using SHA-256 is a security best practice for SAML 2.0 scenarios, and multiple Identity Provider vendors are enforcing the usage of SHA-256 as the default algorithm.

Since for most scenarios (specially for cloud systems) the impact of changing the algorithm is minimal, I can't see why not use SHA-256 algorithm for a new implementation from the start.


Is it possible to retrieve embedded information in a printed image with steganography?

It depends.

Steganography is basically hidden information. It can be as simple as a picture that is mirrored versus a non-mirrored picture. This would convey one bit of information, and may not be easily detectable to an adversary. It would survive even extremely crude reproductions.

If you however hide data in the least significant bit of the colorspace, it would likely not survive, as color reproduction is not that accurate. It also depends on data density; fewer bits with a lot of space used for error correction will give you higher chance of success.

In essence this is a question about the bandwidth of the reproduction. A digital reproduction (e.g. copy of the file) is identical to the original. When you print it, you somehow transform it from digital information, to colored dots on a page. With what accuracy does this process happen? Do you rescale it, so 10 digital pixels ends up being 2-3 colored dots? Is the same color space used? Digital images are commonly RGB, while printed images are commonly CMYK.

When you scan the image you take these dots, shine some light on them, and digitize the return. How accurate is your light source? Is it a cheap LED with a very narrow light color? How accurate is your digital sensor? What resolution can you achieve?

As for your picture, I doubt you'd be able to recover much. The resolution is poor, and there's white and black dots at the size of individual pixels. Paper exhibits bleeding, as ink is a liquid,and paper is a fiber. The problem of bleeding even led to development of ink traps in typefaces to make characters sharp. A print medium could probably not reproduce a single white pixel surrounded in black.

On the other hand,it's two colors. If you print it in large enough scale, you will be able to accurately recover all information present, given that you know it is in two colors only, and pixels are printed significantly larger than any bleed effects. What size this will be probably depends on printing technology and paper stock used.


Automated tools for Cisco IOS config auditing?

Cisco's own SDM (Security Device Manager) performs some basic auditing.  "Cisco SDM allows users to perform one-step security audits to evaluate the strengths and weaknesses of their router configurations against common security vulnerabilities."  For a list of features included, see AutoSecure Features Implemented in Cisco SDM .

Another well-known tool is Cisco RAT, available from the Center for Internet Security.

These are good starting points, but far from perfect.

A more recent option (which I haven't tried yet) is the Nessus IOS plugin from Tenable.

More ad hoc (single-function) tools can be found at

http://packetstormsecurity.org/cisco/page1/
and
http://www.cymru.com/Tools/index.html


What are the security implications of "Row Hammer" attack?

The basic security implication is that an unprivileged user can elevate their access to root/kernel level.

Google's Project Zero tested 29 different laptops manufactured between 2010-2014 inclusive, and found that 15 were vulnerable and 14 were not. They do warn that this sample size is not enough to be considered representative, but it is still suggestive that this is unlikely to be an isolated problem.

The original Flipping Bits in Memory Without Accessing Them paper suggests that the problem is much wider:

  Among 129 DRAM modules we analyzed (comprising 972 DRAM chips), we
  discovered disturbance errors in 110 modules (836 chips). In
  particular, all modules manufactured in the past two years (2012 and
  2013) were vulnerable

The only real way to mitigate the attack is to not run arbitrary binaries on your system, and to not allow anyone else to access your system if they might have hostile intentions. This is obviously a problem for shared computing resources e.g. universities, hosting facilities etc. Cloud providers could potentially be vulnerable (successful memory corruption from inside VMs has been reported, but it remains to be seen how exploitable this is).

Using ECC, whilst not a guarantee of security, might lower the probability of successful exploitation. The full mitigation is to update to a system that employs some defence - either a memory controller or DRAM that actively detects and avoids the exploit. Availability of such controllers or DRAM right now is unknown, but they are known to exist. Memory manufacturers have been aware of this problem for a while, and the specification for LPDDR4 includes mitigations, so future laptops will be protected.


Do I need to associate my backend API server with a domain name to get an SSL certificate for it (HTTPS)?

It seems that it's not possible obtain a certificate from Lets Encrypt for a public IP address, without a domain name.  See https://community.letsencrypt.org/t/certificate-for-public-ip-without-domain-name/6082.
Notwithstanding, are you sure you really want to ask users of your API to access it by its public IP?  If you ever need to move your API to a different server, this will require all of the users of your API to change their systems that call your API, to replace the old IP with the new one.  This will undoubtedly frustrate your users, and it will cause the migration to take much longer.  Using a FQDN (e.g. api.yourdomain.tld) will make this process much more agile if you ever have to change servers - just update the A record of your FQDN, and your're done with it - without your users having to do anything.  And, you can get a cert from LE.


Would it be considered good practice to make the salt for a password the hash of the user's username?

No.

Remember that people tend to reuse passwords from service to service. If two systems use your scheme and someone uses the same username and password on both systems, then they will end up with the same hash in both cases.

Salts aren't secret, and technically the randomness requirement on them isn't as strong as what is required for cryptographic keys, it is best to generate them the same what that you would generate keys just to avoid this and other sorts of mistakes that people make when creating salts.


Any issue with allowing CORS on an oauth2 endpoint

If you are restricting the output of CORS headers for trusted client IDs and origin combinations only then this should not open up your site to any CSRF attack vectors.


Does PKCS #7 (CMS) add assurance to an email if a CRL/OCSP response is included, then revoked?

What you are looking for is theoretically viable, provided that you add the missing extra piece, i.e. some form of time stamping. However, behaviour of existing, deployed implementations is likely to be a problem.

The conceptual idea is that if you verify a signature at date T on some message, then, at a later date T', you can still remember that the signature was correct, and act on that belief -- even if the signature is no longer verifiable at date T', e.g. because the signer's certificate was revoked in the mean time.

In the case of revocation, each revocation information (be it in a CRL or an OCSP response) comes with a revocation date. The field is called revocationDate in a CRL and is defined in the following way:

The date on which the revocation occurred is specified.

So when a CRL says that a certificate was revoked on June 17th, at 14:10 +00:00, it also implicitly says that on June 15th, the certificate was not revoked. Therefore, if the recipient can somehow make sure that he received the email (and its signature) at a date prior to the revocation date, and that the stored email was not altered in any way, then the signature is still, conceptually, verifiable.

A serious hole in the theory above is that existing CA do not necessarily write revocation dates with all the needed accuracy. For instance, if you revoke twice the same certificate with Microsoft's PKI (Active Directory Certificate Services), then the revocation date will be the date of the second revocation, not the first. But if you manage certificates on smart cards with Microsoft's FIM CM product (Forefront Identity Management -- Certificate Management), then you will make such duplicate revocations.

In general, proofs of existence of some piece of data at a previous date rely on time stamps. For long-term archival of signed documents, still verifiable years after (not only after the signer's certificate has expired, but also after some of the intermediate CA certificate have also expired), you need to apply time stamps on a regular basis, like a layer of fresh paint. Some standards exist for that, but they are little more complex than simple CMS (CAdES builds on CMS, but with some rather hairy extra attributes). See this answer for some more discussion and pointers.


What is this strange GET request (GET /A0A32579-2767) DoSed my apache?

From my experience, it looks like you were DoSed with a SlowLoris attack. It would appear that the attacker tried to retrieve a random non-existent page and then used SlowLoris which caused the DoS effect.

Essentially the attacker generated two 16-byte GUID's/UUID's, appended them together with /, and then loaded the index file of /GUID_1/GUID_2. When the server began to reply, the attacker's application then read back the bytes very slowly and thus caused the connection to stay open. Meanwhile, several other threads likely opened other concurrent connections and performed the same process. Thus each of the attacker's threads occupied 1 connection on the server and the server could not reply to any other connections because it was still attempting to serve the attacker's connections with the 404 error.

Because this is considered a layer 7 attack ("Application Layer"; see the image below), a smart attacker could use proxies to prevent tracking and IP blocking.

The best mitigation would be both blocking the attacker's IP Address(es) (or the IP Address(es) of the proxies the attacker used) and installing some server mods which can detect and prevent these attacks. In this article, I read that installing libapache2-mod-qos to the server will prevent SlowLoris on susceptible Apache machines.

It is worth noting that Microsoft's ISS servers are not vulnerable to a SlowLoris incomplete HTTP GET Attack; however, the ISS servers are vulnerable to "R-U-DEAD-YET" incomplete HTTP POST Attacks.


Isn't Autohotkey effectively a keyspectator should I feel safe that I'm allowing this program to watch my keystrokes

You don't have to trust it any more than you trust any other program you run. Any program could steal everything you type if it were malicious; the fact that AutoHotkey reads what you type as part of its legitimate function doesn't make it any less safe.

Further, AutoHotkey is trusted and known to not be malicious. (It's also open-source, so if you don't trust other people to vet it, you can do so yourself and then build from the source you verified.)


I will keep my members password in database with SHA-512 hash. I will
use SALT for password. So i will keep SALT keys in database for each
member. Is it safe and ok to implement that way?

Yes, if you are using salt (which you should) then you should store the salt (in the clear) alongside the hash.

Should i keep IV (Initialization Vector) in the database for each
product so i can use it for encryption? If so i need to expose it via
my API so client can obtain it to decrypt. Is it safe to expose?

It depends on what encryption scheme / mode you are using, but since you mentioned AES-CBC, there is no requirement to keep the IV secret. The only requirement is that the IV be random / unpredictable.

Which encryption and Hashing algorithm is best to use in different
environment without any problem. I will decrypt files in iOS, Android,
Windows Phone, Windows, Mac etc. All native I know it from a friend
that he used AES-128 and MD5 on server to encrypt but he face lots of
problem on different clients when tried to decrypt files.

Encryption and hashing algorithms are language and OS agnostic, you should be able to find implementations in most languages. AES and the SHA family are especially well supported and widely used. I'm not sure what problems your friend is encountering (and generally you'll want to avoid MD5).

I am planning to use AES-256 (Cipher Mode: CBC, Padding Mode: PKCS7,
with IV) and SHA-512. Any comment on this choices?
I am using some data to encrypt or hash files or information. I have
to expose that data over API so my clients can obtain it and use them
for decryption. Is it safe to do it? Is there any other way to do it?

I'm going to combine these two points. I'm going to assume when you say AES-256 and SHA-512 you mean AES for encryption and SHA as an integrity check for the message. There's a problem with this: say you encrypt the message and then compute the hash for integrity. Given that you are using CBC mode an adversary can (for example) do a bit flipping attack and then recompute the hash of the modified ciphertext and you would be none the wiser. In general you would want to use a keyed hash (like HMAC) for integrity and authenticity.
Now (and to your second point), there's something called Authenticated Encryption with Additional Data (AEAD) which will actually take care of the problems addressed in the previous paragraph (will provide confidentiality, integrity and authenticity without having to construct a scheme from primitives). It will also allow that some data (the additional data) be kept in the clear, but will still ensure the integrity of that data. Look into GCM mode (e.g. AES-GCM).

I will store 2 different Validation Password and 2 different
Encryption password in database so i can use it with AES and SHA-512.
But i need to store same passwords in the client code as hardcoded
text so i can decrypt product. But this password can be stolen by
de-obfuscating it. What is the best way keep this 4 password in the
client environment as well as other important client information?

I'm not an expert in this regard but it I would highly advise against hardcoding a password into the client. Any reasonably clever attacker will be able to recover this password in minimal time, so there's really no security gained here.

When i publish iOS, Android and Windows Phone, Windows Store, Mac apps
to the markets then they are getting obfuscated and signed
automatically. I will manually sign and obfuscate my Windows
Application. Is it enough to protect my code against curious people?

My understanding is that signing code / an app is to prove the authenticity of the code to the end user, so as to ensure that an adversary has not backdoored the code /app they downloaded or something along those lines, and not to make decompiling / reverse engineering more difficult. Obfuscation may also not be enough to keep a dedicated adversary from figuring out how your source works or recovering sensitive data in your code. It has always struck me as a case of security through obscurity.


How to backup database to comply with UK data protection act?

Dropbox is compliant with the Data Protection Act, the main worry is point 8 of the Act:

  Personal data shall not be transferred to a country or territory
  outside the European Economic Area unless that country or territory
  ensures an adequate level of protection for the rights and freedoms of
  data subjects in relation to the processing of personal data.

If a company is outside the EU and in the USA then there is a 'Safe Harbor' list maintained of companies that fulfil the the level of protection clause.

Here's a blog post from Dropbox saying they are now Safe Harbor certified and a link to the Safe Harbor site so you can check for yourself, might also be worth checking for other companies you're considering.

Dropbox Blog: http://blog.dropbox.com/?p=972

Safe Harbor List: http://safeharbor.export.gov/list.aspx


Mediawiki/Nginx/Php on Ubuntu 14.04 is being attacked

If you have a server on the public internet, it will be scanned and probed.  This is just a fact of life, and should inform the base of your security policy.

You are most likely going to primarily see three types of attacks:

Spammers will try to make comments on blogs, edit pages on wikis, and in general do anything they can to get links to their sites on yours.
People will run automated vulnerability scanners that try to exploit known vulnerabilities in outdated software and poor configurations.  Sometimes this is a first step towards more destructive spamming (take over your site completely), sometimes it's to make you part of a botnet, sometimes it's just for the amusement.
Sometimes you'll just get plain ol' HTTP requests.  These can be an attempt at a DoS attack, or a misconfigured bot, or a search engine spider, or someone archiving your site to read it offline, or an unexpected link to your site from reddit, or any number of other things.  Whether the intention is good or not, if you're not prepared, this can make your site inaccessible.

It's fairly easy to mitigate most of what you'll see in all three of these categories:

Keep your software up to date.
Don't use anything that says "For development use only!" in production.
Install an anti-spam plugin for your blog commenting system.
Add full-page caching and rate-limiting, either yourself (e.g. with Varnish) or through a service like Cloudflare.

You'll see plenty of requests that won't do anything to you, because it's easy to tell a script to just try everything, rather than trying to figure out what exactly you're vulnerable to.  For the most part, these can be ignored, but keep an eye on your site to make sure a spammer doesn't get in and wreak havoc for months before you notice.


There are new hacks always happening. Here is one in particular that was rather famous. In the late 1990's there was the teardrop attack which was pre-packaged as 'win nuke' which would send a packet to an ip address. The name tear-drop comes from what it did: it created a bad packet, tore it into a pair of half-packets, sent them both to the target ip address. The incomplete packets would not be recognized by security apps and would 'drop it' past the firewall, where the error correction in the network interface would see a broken packet and sew it back up.

The win-nuke app that went all over the net would simply be used to send a packet to someone that would crash the network interface... (denial of service) 'nuke-ing' them off the net until they restarted their network connection. Rather than a 'kill' function, anything that could be sent in a network packet would conceivably be possible.

Ports 139 and 145 were the usual targets because they were vulnerable, so the end result for this particular attack was that they were blocked by firewalls.

Telnetting to a computer (netcat is a tool that people use to do this) to a specified port and sending corrupted data is still used. Just different ones. If you have figured already, this is not limited to windows.


Difference between IDS and IPS and Firewall

The line is definitely blurring somewhat as technological capacity increases, platforms are integrated, and the threat landscape shifts. At their core we have

Firewall - A device or application that analyzes packet headers and enforces policy based on protocol type, source address, destination address, source port, and/or destination port. Packets that do not match policy are rejected.
Intrusion Detection System - A device or application that analyzes whole packets, both header and payload, looking for known events. When a known event is detected a log message is generated detailing the event.
Intrusion Prevention System - A device or application that analyzes whole packets, both header and payload, looking for known events. When a known event is detected the packet is rejected.

The functional difference between an IDS and an IPS is a fairly subtle one and is often nothing more than a configuration setting change. For example, in a Juniper IDP module, changing from Detection to Prevention is as easy as changing a drop-down selection from LOG to LOG/DROP. At a technical level it can sometimes require redesign of your monitoring architecture.

Given the similarity between all three systems there has been some convergence over time. The Juniper IDP module mentioned above, for example, is effectively an add-on component to a firewall. From a network flow and administrative perspective the firewall and IDP are functionally indistinguishable even if they are technically two separate devices.

There is also much market discussion of something called a Next Generation Firewall (NGFW). The concept is still new enough that each vendor has their own definition as to what constitutes a NGFW but for the most part all agree that it is a device that enforces policy unilaterally across more than just network packet header information. This can make a single device act as both a traditional Firewall and IPS. Occasionally additional information is gathered, such as from which user the traffic originated, allowing even more comprehensive policy enforcement.


RESTful web application security and authentication scheme

Authentication is a complex mechanism with a lot of potential security failures that should be addressed.

TLDR: use Open ID for authentication instead of implementing your own mechanism.

Brute Force: you must take care of protecting against brute force in authentication (limit number of wrong attempts to login) and also protect against brute force of your session ID. If I were an attacker I just brute force the pair of ID and session ID until I do not get 401... now I have a valid session. You must block that after too. You can use an HMAC to sign the session ID. That way an attacker cannot guess your secret key used to HMAC the session ID and cannot brute force it.
Session ID theft. You did not state how Session ID is sent back to the user. I assume you meant to send it for client side script to handle and send with each subsequent request. That makes your Session ID susceptible for theft from client side script (caused by XSS for example), the way to protect against this is sending it in a cookie with the "http only" flag set so scripts cannot access it (and you need to make sure also "secure" flag set and limit to your domain etc... )
Your mechanism does not allow the user the "remember me" method, hence user will have to re authenticate every time he opens the app, keeping the session ID in a cookie will solve that as well.
CSRF - if session is kept in a persistent cookie you become vulnerable to CSRF. The way to protect against this is using an anti CSRF token otherwise known as Synchronizer Token Pattern

With all this in mind... my final recommendation for you is using open ID to authenticate your users, keep the hard work of authentication to the big guys and only make sure you are using it right, that will save you allot of headache and time and would probably eventually be more secure.


In theory, it may also be possible that multiple sessions are shared by a single connection.

This is true, but not at the same time. Instead an active SSL session inside the connection can be replaced by a new session using renegotiation. Renegotiation is required if the sequence number of a TLS session would wrap (i.e. after 2^64-1 SSL frames) which is unlikely in practice. More common is a renegotiation of a session without client authentication to a session with client authentication (i.e. client certificate). This can happen in HTTPS if only some parts of the site require client authentication and the browser tries to access some URL which requires such authentication while already having an established connection.

Multiple SSL sessions after each other inside the same TCP connection can also happen if after the TCP connect there is an SSL handshake followed by an SSL shutdown  later and then again an SSL handshake inside the same connection. While uncommon it can be done in FTPS where AUTH TLS is used to initiate an upgrade from plain TCP to TLS and CCC is used to initiate the downgrade from TLS to plain TCP.


How could an attacker exploit XSS in a cookie reflecting the URL?

The escaped string, %22%3e%3c is URL encoded. The URL encoding makes it impossible to escape the quoted attribute value context, since all interesting characters will be converted to their URL encoded percent values.

So can this URL encoding be avoided? I don't know. If it is the escape() function doing it, you might be toast. However, depending how you perform the attack it might be some browser magic somewhere URL encoding things. Try execute the attack under as realistic cirsumstainces as possible - e.g. craft your malicious link and click it, instead of entering the URL in the adress bar.

Finally, it sounds like the a element in question might be generated client side with javascript? I imagine the code might look sort of like this:

theLinkElement.href = "./" + foo

If this is the case, it's game over since many classic XSS tricks don't work when you are explicitly manipulating the DOM via javascript.

But what about that leading ./? Is it hardcoded? Can you get around it? If so, a javascript: URL would do the trick.


Can multiple SAQs be used for PCI compliance?

There is a relevant FAQ from the PCI SSC that addresses this questions. The gist of it is that you if the environment meets the criteria for the SAQ then you can use that SAQ as a reference for the requirements you need to meet for that environment.

In practice you would complete SAQ D and evaluate your responses based on how they pertain to the two environments. Each legal entity should only complete one SAQ or ROC for the entire company. To complete multiple SAQs would be misleading, as you can't answer truthfully to all criteria needed to complete either the SAQ A or C-VT, as the requirements for doing so apply to the company as a whole, and all SAQs besides D have stipulations that there are no other cardholder data flows.

When conducting your review, if neither SAQ A or SAQ C-VT contain a particular requirement, meaning the PCI SSC has deemed it not applicable for a particular  type of environment, you can mark it as N/A in the SAQ D you are completing. If either one of them contain the requirement then you should evaluate how you are meeting that requirement for the related environment and document it accordingly.

The key to this method, as it states in the FAQ, is clearly documenting and explaining the approach you are taking in the Executive Summary of the SAQ. You need to clearly document and explain how the two environments are separate and individually qualify for a given SAQ, and the approach for evaluating each requirement for compliance.


Do It Yourself Credit Card Storage (PCI - DSS Compliant)

The PCI DSS isn't expressly clear on this topic.  The meaning of secure key storage and secure key management is left up to the QSA's interpretation.  You may find that that one QSA considers the private KEK to be all that needs to be secured, and he treats the EKs as tokens.  Or you may find a different QSA that sees every individual EK as needing to be secured, even though they've been encrypted with a KEK.  We've had both kinds of auditors, and frankly, I thought the "harsher" of the two was more competent (even though I disagreed with his assessment of the risks.)

The bigger problem I see is that you're not taking into account the cost of owning this system.  A complex system like this is going to take time and money to build.  It will require the auditors to make a very careful examination of all the nooks and crannies of the systems, which will also take a lot of time and money.  And they'll have to repeat their examination every year.

Consider that under the current rules, if you build a system that gets breached, the rental guy will be liable for 100% of the costs of all fraud associated with the breach. That means if someone steals a millionaire's card and charges a Ferrari on it, he's liable for the loss.  If someone steals 10 millionaires' cards and charges one Ferrari on each of them, he's liable for the whole loss.  His lawyers, of course, will immediately turn around and sue you for building an insecure system.  And they will sue the QSA for incompetence at not telling them that your homemade system was insecure.  So the QSA has to charge enough not only to pay for the time spent auditing the system, but also some insurance to cover their risk.

Frankly, the rental guy would be better off having his counter employees making photocopies of customer ID cards and dropping the copies into a drop-box type safe under the counter; and keeping his security cameras rolling.  If a customer fails to return an item, or returns a damaged item and contests it, he'll have the evidence he needs to bring the renter into small claims court.  That's a whole lot cheaper than building a PCI DSS compliant system and maintaining it.  (And that's really the point of the PCI DSS - the auditor should identify and explain the risks, the business owner should carefully consider the risks, and then make wise choices.)


Does the stackexchange mobile app use HTTPS?

The Stack Exchange network is only accessible over HTTPS. If you try to access it over HTTP, you'll just get a redirect:

% curl --include http://stackoverflow.com/
HTTP/1.1 301 Moved Permanently
Content-Type: text/html; charset=utf-8
Location: https://stackoverflow.com/
[…]

Additionally, Apple has measures in place to incentivize apps to use HTTPS. Apps are required to explicitly declare which servers they will use HTTP to communicate with, and Apple may reject apps which are not using HTTPS appropriately.


how to force openvpn client to use TLS instead of SSL connection

You have tls-version-min 1.2 in your configuration file, so you are using TLS. It appears that your logging tools is simply referring to SSLv2, SSLv3, TLSv1.0, TLSv1.1, TLSv1.2, and TLSv1.3 all as simply "SSL". This is technically incorrect, but it's very common. You don't have to worry about SSL-specific vulnreabilities in your application just because the protocol itself has been labeled as SSL.


This was fixed in the Firefox 48 release, there is a security advisory on the Mozilla foundation's website. It seems that it only affects the Android version of the browser, so not only are you using a release that has been properly patched, but if you're using a desktop browser you would not have witnessed the vulnerability otherwise.

  Security researcher Rafay Baloch reported a mechanism to spoof the addressbar in Firefox for Android using right-to-left character sets when combined with left-to-right characters. This can be used to cause only certain portions of the loaded left-to-right character portion of the URL to be displayed, misleading users as to what site is loaded, possibly leading to phishing attacks.

  This vulnerability does not affect the desktop version of Firefox.

Link to source


How secure is aSSL (javascript)? Does it effectively mimic SSL?

How does it protect from man in the middle attacks? From what I gather, it doesn't at all (can't think of a way it could actually). That makes it perfectly useless.

SSL/TLS kinda works because because you trust the software telling you the connection is secure (in the usual case your browser). When you download the code telling you that the connection can be trusted from an attacker, all bets are obviously off.

I may be wrong as the documentation is quite thin, but it doesn't look good at all (to be polite).


In what situations does parameterizing a query NOT prevent SQL Injection?

The only one that immediately comes to mind is second order injection where a value such as 123' or 1=1 -- is stored in a table which is later retrieved and then used unfiltered in a query. It does usually require the code to not parameterize data retrieved from the database which is not that uncommon as developers often consider this a "trusted" source.


Why does setting cipher text to 21 characters mean plain text is nothing in AES256

My guess ist that you are referring to this JS library. While the incomplete documentation suggests that it does AES-256 with the given key and cipher text a look at the code suggests that it does something else: The key is not the AES key but the AES key will be derived from it using SHA256. And the input is not the cipher text but will be treated as Base64. It will also use the first 16 byte of the decoded input as IV and then decrypt the next 16 byte. This means to cover at least 1 byte of plain text your input need to be an 17 byte binary (16 bytes IV + 1 byte data). This 17 bytes binary results in a 23 byte long base64 encoded string and any input shorter than that will just not contain any data to decrypt.


How does browser verify if SSL certificate is issued by CA?

How does browser verify if SSL certificate is issued by trusted CA? Do browser verify this by ask CA's server? Or it's just the case that only CA can issue those certificate.

You want to read about the topic digital signature. A digital signature allows someone (the CA) to claim that they have authored a data (a certificate containing claims), in a way that are impossible to forge.

Understanding digital signature starts with Public key cryptography. The CA creates a pair of keys: private and public key, that are mathematically linked such that using their private key and a hash of the data, the CA can compute a number (the digital signature) that can be verified by other people that had the linked public key.

Browsers ships with the public keys of a number of trusted Certificate Authority, which it uses as the root of trust. Using this repository of public keys, the browser doesn't need to contact the CA to validate the signature (though note, it does need to contact the CA to verify that the signature hadn't been revoked).


Certificate verification fails for self-signed certificate

From the comments:

  Is this really a CA certificate, i.e. has it basic constrains CA true? ... – Steffen Ullrich
  @SteffenUllrich you're right it has: CA:FALSE – little-dude

Signing a certificate requires that the issuer certificate must have the correct flags so that signing is actually allowed. To correctly sign a certificate the issuer certificate need to have the basic constraints CA set to true. This is true both when signing another certificate as for signing the same certificate (i.e. self-signed). It looks like the certificate had not the correct CA:true flag in the case here.

Moreover, the --cacert option is like its name says only for CA certificates and not for arbitrary certificates. For example if you have the leaf-certificates of a site  you cannot just add is as trusted with --cacert since it is (usually) not a CA certificate. It will simply be ignored when reading the certificates from the given file.


Is it possible to hash bcrypt passwords more securely?

Usually the authentication work as follow:

The user enters the password
The password is passed to a password verification function such as
password_verify($enteredPassword, $storedHash) in PHP
The function generates the appropriate rounds of the configured hash
function (take it from the hash value itself) and compare it with
the stored hash in the DB.
If both are equal, the authentication is successful.

The only thing you need to do is take the $enteredPassword and generate the hash through the new work factor procedure and store the new hash value in the DB.

Another option is to just prompt the user to update his/her password after they are logged in to the application.


I received an "Undelivered Mail", is my email address used maliciously?

In addition to @SteffenUllrich, you might also want to double check the headers of the attached mail.
In particular, pay a lot of attention to the Received: from header (well.. the header is just Received...).
Two circumstances (asssume mx.example.org is the server who sends the return):

You don't find your own MX on the stack. ✔ Case closed, someone is (failing at) spoofing your email

You do find your own MX somewhere on the stack. Now check:

If your server is the first entry after mx.example.org…
 You must investigate further. Your account might really have been pwned (because of a leaked password) to be used for spam. You may want to check your password for leakage at haveibeenpwned.com and the server logs for suspicious activity.
Another interpretation is that the header, which is just a plaintext header, was forged. This would mean that there is no attempt to deliver mail at someone@example.org but instead someone else is trying to deceive you into thinking you sent an undeliverable mail. It is unlikely, but without checking the contents of the attached email for malware, it's just hypotetical. Also, don't forget that the foreign mail server could be poorly configured, worse than not just checking for SPF/DKIM.

If your server is not the first entry after mx.example.org…
⚠ This means that the email claims to have bounced back and forth. It is unlikely, especially for how SPF works. Unless some strict corporate routing configuration for firewalled stations, emails travel non-stop from the origin ISP to the destination ISP 99.9% of cases. In that case, the header was very likely forged to give more credibility to the email, deceiving old antispam filter ("hi Mr. mail server, I have to deliver a mail to you that was given to me by the intended sender"). I'd still trash it, but maybe you would take a look, low priority, at the logs for message id. Just as a triple-check.

You can somewhat reduce the problem of such misuse by having strict SPF policies (and better also DKIM and DMARC) but this does not help much if the initial mail server will not check such policies or not block the mail based on the policies.

This was my case, and apparently the server never enforced those policies on their side to discard that mail allegedly coming from myself. Case closed.


Interrupts have substantial performance overheads, linux has moved to syscall/sysenter on x86 where supported. The VDSO pseudo-dll "linux-gate.so" (which ldd will show) makes the platform-specific fastest call, you can read more here:

https://stackoverflow.com/q/12806584/1955371 (What is better “int 0x80” or “syscall”?)
https://stackoverflow.com/q/9506353/1955371 (How to invoke a system call via sysenter in inline assembly (x86/amd64 linux)?)
http://kerneltrap.org/node/531 (Linux 2.5 gets vsyscalls, sysenter support)

Code that uses 0x80 will continue to work, though current glibc versions won't use that method on modern x86 platforms and linux kernels.


What is the difference between Key, Certificate and Signing in GPG?

In public key cryptography, the key is usually a key pair, consisting of a public key and a private key, and it is what you do encryption, decryption, signing, and verification with.

"A key certificate is an assertion that a certain key belongs to a certain entity" PGP lecture.

To illustrate what each key does, and to see an example of why one would both encrypt and sign, consider Snowden (S) and Greenwald (G):

Each of them creates their own key pair, and they publish their respective public keys.
Assume (for now) that the public keys are trustworthy.
Say S wants to send a message to G. To do that:

S looks for G's public key.
S encrypts the message using G's public key.
S signs the encrypted message with his own private key.

G receives an encrypted signed message. The untrusted email header says it is from S.

G looks for S's public key.
G verifies the signature using S's public key. Now, G is convinced message is from S.
G decrypts message using his own private key.

Note that signature and encryption are performed using different keys (by S). Without the signature, G would still be able to decrypt it, but he would not be convinced the message is really from S.

The whole scheme relies on the assumption that public keys are trustworthy. Otherwise, for instance, the spook K might publish a key with G's name and intercept G's email, so that when S sends the message, K decrypts it instead of G. This is where key certificates come into play.

However-however-however! This whole public key cryptography is only useful to implement secure communication between a trusted and an untrusted party. E.g., from G's pov, he does not trust S at the time when S wants to send him a message. Then: public key crypto enables G to receive encrypted messages meant only for him from an untrusted sender S.

If there are no untrusted parties in your scheme, there is no need for all this stuff. Instead, you and your boss should agree on a strong key/passphrase. Then, you could encrypt the message with traditional symmetric encryption using that shared key with gpg --symmetric --armor, and he could decrypt it with gpg --decrypt. This is how the command lines would look like. GUI and integration of GPG in email clients would be another topic.


Your interpretation is incorrect. WPA2-PSK doesn't completely encrypt layer 2 information.
Management frames are unencrypted (except in cases where management frame protection is implemented). MAC addresses of all communicating parties can also be observed, which somewhat helps to analyze communication flows and gain general information on the network. The sizes of exchanged packets are visible as well, being somewhat useful in understanding what's going on in the network. An attacker can also send dis-association frames, which would cause denial of service.

The payload of the 802.11 frame IS encrypted, meaning that layer 4,5,6 and 7 information IS encrypted.

That encryption is only for the network "outsiders", running PSK would allow you to eavesdrop once you've got the key and you're on the network. This is where other layers' protocol security kicks in (HTTPS, SSH, etc.).

In general, from a practical security point of view, WPA2-PSK would help guarding the integrity and confidentiality of information, but doesn't quite help with availability. For obvious reasons the integrity and confidentiality only rely on the strength of the PSK, which often is less than perfect. There are plenty of posts here on WPA2 and its security, I'd suggest looking around for more information.


Well, for starters, a token can be expired in a relatively short period of time, forcing a user to re-authenticate.  A password is generally has a much longer life.  Thus, if a token is stolen by an attacker it is useful for a relatively short period of time (this is one reason that when you have to change a password a good system will force you to enter the current password).

In addition, if you put a hashed password on the client then it can be stolen and used by an attacker in "pass the hash" attacks, which have been around for over twenty years now.  It'd be nice to get rid of them :-)


"Threat Intelligence" has to have "threat" as a context. A piece of data is just that: data.

The wiki page links to the CERT-UK's paper on the subject and defines threat intelligence as:

  [It is] evidence-based knowledge, including context, mechanisms,
  indicators, implications and actionable advice, about an existing or
  emerging menace or hazard to assets that can be used to inform
  decisions regarding the subject's response to that menace or hazard.

[quoted from: https://www.gartner.com/doc/2487216/definition-threat-intelligence]

So, just having the geo-location info is the same as having the IP: it's a piece of data. There is no particular relevance to the data, so it is not "threat intelligence". If it was known that major attacks were happening from a particular location (as has happened with Chinese Army attacks coming from known military locations and the IP geo-location data pointed there directly) then that context makes this particular piece of data "threat intel".

Just because the geo-ip data is odd for you in this instance does not make the area of knowledge called "geo-location" threat intel. But I'm not sure why one would require that the data be classified this way.


How do websites protect against 2fa replay attacks?

You can black list reuse. Simply save time (or code) of previous login, and force the user to wait until new OTP is generated. Generally TOTP tokens are updated every thirty seconds.

You can use counter based OTP; re-use will never occur as both devices increment the counter.


Use a Common Firewall for two Different Subnets

I may be way off here, but if one building has the domain controller, and the other has the firewall, why don't you just set traffic of OB1 to route through the VPN to your gateway(10.0.1.167). There isn't sufficient information to really give you much guidance. Questions that I have are, how is your VPN implemented? Are you willing to take a hit on your bandwidth if you route all of your traffic across a VPN just so it can go through a web filter? What if one of the buildings goes offline, how will it affect the other? In short, it sounds doable, but is that going to be the best solution long term?


In a SAML2 FSSO Web Browser profile (HTTP POST), should the IdP analyse the AuthnRequest before asking the user to authenticate?

The Authnrequest should be validated first check signatures, timestamps and so on. Plus the AuthnRequest can contain information on how the user should be authenticated so logically reading the AuthnRequest comes first.


SSL and Strategy to prevent destination URL from being revealed

You're thinking of a reverse proxy. The submission target isn't the actual target but a proxy that relays the data to the actual target. I don't see the point of such strategy from a security point of you. The security of your system must not rely on it being obscure or hidden, it must be an intrinsic property of the system itself. The problem is that you're looking into this from the wrong angle; this has nothing to do with vulnerabilities in SSL/TLS.

Even if CRIME and BREACH never existed and no secrets in the SSL/TLS sessions were possible to reveal, all it takes is for someone to use your application to reveal the submission target server. Actually, they don't need to do that, they can simply look at the traffic to see where it's going. SSL/TLS doesn't hide the destination IP address, and the vast majority of DNS queries are sent in the clear.

This is just one layer of obscurity that should be discussed after the underlying security has been thoroughly assessed.


Adding a SSL builds trust with technical clients?

An SSL Certificate provides three things:

confidentiality
integrity
authentication

However it only provides these three things to the connection between client and server. Does this make your website more secure? Yes and no.

It ensures as you say that prying eyes will not be able to sniff username and password when this data is in transit between client and server.

However SSL does not provide any guarantee on the way you coded your application, manage your server, handle confidential data or grant and distribute privileged access. Security is much more than just adding SSL certificates to a website. It is parth of the solution, but not the complete one. Security has to be performed in depth.

TLDR;

So can it help build trust? Well the user will know his username and password can't be sniffed, but if your application is coded badly and you use admin:admin as server login then there are other, easier attack vectors which attackers may abuse to gain access to your user's data. But most of all this will largely depend on the awareness of the user.


Maybe is not classified as DoS attack but I think yes, this could cause DoS if you are able to generate enough traffic. To protect this you can use something like fail2ban


Is the OpenPGP implementation of the YubiKey 4 Open Source?

No, the Yubikey 4 is not Open Source:

The implementation is not open source, that is correct. We have both internal and external review of our code to ensure that it is secure. It's important to remember that open source code is no guarantee that bugs/vulnerabilities will be detected as the bug you've linked to demonstrates quite well. The bug was inherited from the upstream project which ykneo-openpgp is based on, and was NOT detected by any audit of the source code. It was interaction with the device itself which lead to it's discovery.
We're all for open source, and we try to open source as much of our code as possible when and where it makes sense, but in this case it was determined not to be so. One reason is that on the YubiKey NEO, each applet runs in its own sandbox, isolated from the rest of the system and can be audited/reasoned about on its own. This is not the case on the YubiKey 4, where each part of the system interacts with several others. Another reason that ykneo-openpgp was implemented as an open source project (aside from being able to leverage an existing project) was that it was useful for others, as it can run on a variety of devices. Again, this is not the case for the implementation running on the YubiKey 4.

Although older devices such as the Yubikey NEO used an Open Source applet, the newer Yubikey 4 devices quietly switched to a proprietary, closed-source implementation.


Security of OpenVPN against sophisticated DPI solution

DPI threats against OpenVPN is pretty hard, unless the attacker somehow grabs the random, freshly generated session keys which is transmitted over an SSL connection. The SSL connection, in turn, is secured using a pre-shared certificate and a secret server certificate. So an attacker would need to compromise the server itself. Usually, said attackers would not go through the trouble of compromising a very secure server unless the target is high-profile.

Deep packet inspection, as far as I know, is usually effective in non-encrypted connections. HTTPS is usually effective in foiling DPI unless you are up against powerful entities (rich kids, government, etc.)

This is the gist of my point. For further reading, refer to my sources below.

Sources:

https://openvpn.net/index.php/open-source/documentation/security-overview.html

TLS Authentication/OpenVPN/MITM Attacks on Public Wifi

How is it possible that people observing an HTTPS connection being established wouldn't know how to decrypt it?


Does returning a 401 error from an API leak information?

First off, if these user IDs are actually sensitive information as you say, do not put them directly in the URL. Why not just make opaque URLs instead and solve the problem before it even occurs? If you remove the relationship between the URL and the user(s), it will be next to impossible to deduce any relationships from a returned status code.

For example, instead of:

GET somepath/customers/123456

just implement some sort of small hashing system with a 2-way look up table and you can use a different URL such as:

GET somepath/DC884298C70C41798ABE9052DC69CAEE

Sure, this takes a bit more work, but if you are legitimately concerned about the issue, it's really a trivial implementation.

Back to your actual question, the W3C states that if someone attempts to access a resource, but is not properly authenticated, then it is OK to return 404, rather than 403 (Forbidden):

  If the server does not wish to make this information available to the
  client, the status code 404 (Not Found) can be used instead.

By the same logic, I don't see why it wouldn't be fine to return 404 instead of 401 if the client is authenticated but not authorized. But keep in mind that, with this approach, someone who is actually trying to work with your API may be confused and just assume that the resource doesn't exist and not realize that they just don't have sufficient authorization. This is ultimately up to you to decide. I will say that, in my experience, I have seen both methods implemented before. If you do choose to return a 404, make sure that you specify this somewhere in your API docs so that other developers are aware.

Source: https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.4


Is there any concern regarding a database primary key exposure?

It depends on what the primary key is. If the primary key is the user's email address or other personal information, then obviously you should never expose it to anyone other than the user. Even if the primary key were the username in the form of FirstName.LastName you should be weary of exposure. Typically though, the primary key will be either an integer or guid which has little meaning by itself, and so I will base the rest of this answer on the typical case.

In general, if the application is designed and secured properly, then revealing meaningless User IDs should not pose a security risk. However, this is not true for all primary key fields in the DB. For example, suppose there is an email validation table that has a guid that appears in a link that is emailed to the user. Those single-use IDs should not be made public because otherwise someone would be able to submit a fake email address and still validate it.

Their are other considerations too that are not necessarily related to security. For example, if you use integer IDs, and you have a public profile page like Matthew mentioned in his comment, then someone could iterate through all of your users and find out information that perhaps they should not know. Examples might be the demographics of your user base, or the exact number of users that your website has, etc. Note this would not be a problem if you use random guids for the primary key, or if you do not expose the public users by the primary key.


Are long-lived SSL/TLS certificates acceptable for non-public resources?

Afaik, 1 year limit is only for CAs that participate in CAB Forum. Compliant clients differentiate public CAs and private CAs and apply different rules. That is, compliant browsers won't alert on a 2yr TLS certificate from private CA (as long as it is trusted). A quote from CAB Forum page:

You might also consider moving some certificates from public to private trust, which also helps with management – you could even issue certs with longer validity using that method.


What should a Vulnerability Management System scan on a large scale

Scan everything; all ports and protocols.

Scan of open TCP ports:

Scanner sends TCP SYN to 1650 targets × 65,536 ports = 108,132,750 160-bit IP headers + 108,132,750 160-bit TCP SYN packets = 34,602,480,000 bits @ 1 Gbit/s = 32.23 seconds; of course, you'll have to go at least twice as slow so that responses from below can use the bandwidth.
1650 targets × 65,535 ports respond with 108,132,750 96-bit ICMP PORT_UNREACH packets or 108,132,750 160-bit IP headers + 160-bit TCP SYN-ACK payload = not more than 34,602,480,000 bits @ 1 Gbit/s = at least 32.23 seconds.
All listening TCP ports on all systems on your network can, theorethically, be discovered in 64.45 seconds if there's no packet loss (OSI layer 2 frame sizes not taken into account).

It's similar for UDP; however, the payload is smaller.

The discovery of all listening TCP and UDP ports on all systems on your network can, theorethically, be completed in 128.90 seconds (OSI layer 2 frame sizes not taken into account).

Other protocols = 1 packet per target in each direction; however, DHCP servers wait on each other, so to discover all of them is a bit more complicated.

I'd say all directly available services on your network can, theorethically, be determined within 180 seconds.

Then you have to scan each directly available service for vulnerabilities. A rough estimate would be that you have 1650 × 5 available servies = 8,250 directly available services. I'd say it would take no more than 10 seconds per directly available service on average. Therefore, all directly avaialble services can, theorethically, be scanned for vulnerabilities within 180 seconds + 8,250 × 10 seconds = 82,680 seconds = 22.97 hours.

Realistically, it will take at least 3 days @ 1 Gbit/s.

Now, just so you know, a hacker could discover all vulnerable standard services on your network within a few hours, if he's a script kiddie, or within an hour, if he's not. That is to say, your entire network can be pwned within 3 hours if there's an entry point and there are vulnerabilities, depending on who's doing it.

That's only IPv4, though; do you have IPv6?


I looked it up, so i'm no expert, but it seems to mean this.

When code is conditional, for instance by using an 'if' statement, a CPU must decide which 'branch' (the if or the else) to take. However, in modern CPUs, instructions are pre-fetched and some calculations are made on instructions not yet executed, so branching poses a problem: which branch should be evaluated? Multipath execution (http://csd.ijs.si/courses/processor/chapter4/sld072.htm) means evaluating both branches, and discarding the branch that eventually turns out not to be the taken path.

In relation to CFG: when taking multiple branches, multiple edges will be temporarily travelled. However, after the condition has been fully evaluated, only one edge will remain, the others will be discarded.

Have a look at http://en.wikipedia.org/wiki/Branch_predictor for a lot of info on how a modern CPU can deal with branching.

This seems to me as not being a typical 'malware' issue, but a general debugging concept.

Someone correct me if I'm talking nonsense :-)


Found this question here: https://superuser.com/questions/737046/ipsec-with-or-without-l2tp

  IPsec has been developed for IPv6, which does not know NAT anymore and using IPsec for IPv4 has always been some kind of hack. Not having NAT for the so called road warriors using IPv4 was a no-go. The only way to get it working in the 90th was to use L2TP, because L2TP works on top of UDP and NAT is possible.

My understanding is then this:

L2TP is used with IKEv1 for the 'road-warriors' / people needing to connect remotely to a network. It bypasses the limitation of IKEv1 not having NAT, or requiring the client to configure their own routing table to talk to clients on the remote network
IKEv2 supports NAT which enables the remote worker to talk to clients on the remote network, therefore L2TP isn't required. IKEv2 also has many other advantages.

L2TP probably isn't used for site-to-site VPNs, or for transport mode as routing tables are set up by administrators, or the communications are happening internally.
L2TP isn't used by itself since there's no encryption, so IPSec is secured to a gateway (with IKEv1), then L2TP takes over at the gateway through the IPSec connection to talk within the network.
You could technically use L2TP with IKEv2, it just isn't required. It would also have a performance impact, and probably other drawbacks, with no benefit.