There's extra status output but it goes to the StdErr stream. So it goes to console (i.e. screen display) and does NOT go down into the pipe. Regular output is part of the "StdOut" stream. That stream goes into the pipe. This is valid for *nix and Windows, too.

Here's an example.

Generate a key:

C:\>openssl ecparam -name secp256k1 -genkey -noout -out secp256k1-key.pem

If you redirect nothing then both streams end up on the screen:

C:\>openssl ec -in secp256k1-key.pem -noout -text
read EC key
Private-Key: (256 bit)
priv:
    00:d6:09:84:21:77:32:86:bb:5d:c9:da:30:ce:dc:
    98:28:f1:f2:f2:2e:2a:9a:91:28:c3:88:b2:bb:80:
    51:24:39
pub:
    04:e3:4b:2c:96:44:08:18:9f:37:bb:b5:8e:44:52:
    69:f4:4b:7f:a7:2a:61:9e:5a:39:1a:07:7a:d6:27:
    e8:8f:83:36:fa:a6:72:e9:f5:7c:41:53:0c:b6:16:
    ab:24:7a:0d:82:2c:b9:cc:2d:2b:08:38:83:e2:ac:
    4e:d7:9a:09:91
ASN1 OID: secp256k1

If you throw away stream "1", which is StdOut, then what you are left with is stream "2", which is just StdErr:

C:\>openssl ec -in secp256k1-key.pem -noout -text 1>NUL
read EC key

You can throw away stream "2" as well:

C:\>openssl ec -in secp256k1-key.pem -noout -text 2>NUL
Private-Key: (256 bit)
priv:
    00:d6:09:84:21:77:32:86:bb:5d:c9:da:30:ce:dc:
    98:28:f1:f2:f2:2e:2a:9a:91:28:c3:88:b2:bb:80:
    51:24:39
pub:
    04:e3:4b:2c:96:44:08:18:9f:37:bb:b5:8e:44:52:
    69:f4:4b:7f:a7:2a:61:9e:5a:39:1a:07:7a:d6:27:
    e8:8f:83:36:fa:a6:72:e9:f5:7c:41:53:0c:b6:16:
    ab:24:7a:0d:82:2c:b9:cc:2d:2b:08:38:83:e2:ac:
    4e:d7:9a:09:91
ASN1 OID: secp256k1

As for the "Why?": I don't know. I think that's just one of the many quirks of the OpenSSL command line utilities.


Tools/methods helping to determine application/protocol serving specific port

The short answer is that you need to talk to the port to see who answers. Two things can come from this:

banners
protocol traffic

The problem is that banners can be faked, so you need a tool to analyze the traffic in order to get an accurate picture.

Tools:

netcat/nc/ncat - useful for basic banner grabbing
sbd - like nc, but encrypted - useful for basic ssl-based banner grabbing
nmap - the king of service detection (use -sV)
wireshark - in-depth protocol analysis with some built-in features (use when using the other tools)
scapy - for really in-depth raw protocol analysis
amap - an application mapper
other focused tools for certain protocols like httprint

Metasploit has a long list of service scanners, but they are best to supplement a more direct service analysis. I highly recommend that you shift away from Armitage until you have more experience with the tools above and with the msfconsole. Then, Armitage can improve your productivity.

Other Methods:
The more efficient method is to ask the target operating system what it is running. If you can query SNMP, you might get a service and port list handed to you. If you have shell access, you can run commands to list running services.

Pro Tips:
Be careful that the tools you use don't simply lookup the port number in a table of common services. It is easy to run services on non-standard ports. Also, make sure you scan over the entire 65,535 port range in both TCP and UDP. Some tools, including nmap, improve performance by only checking the most common port numbers, which means they can miss common services running on non-standard ports (ssh on port 8022, for instance). Warning: UDP scans can take a very long time.


When do shared disks "leak" data to other VMs, and how is that mitigated?

Cloud providers can provide single tenant hardware so your VMs are isolated from other customers and clients. A number of financial regulators are expecting this to be enabled for confidential / regulated data when stored in the cloud.

For example, Amazon AWS has the concept of a 'dedicated instance' (link)

If you select this option your EC2 instances will be on dedicated hardware for your account, you of course pay a premium for this service with the benefit of reducing side channel attacks against your shared infrastructure at OS level.


Is it possible to safely access a USB pen drive in Windows via a virtual box with Linux?

Assuming you do not use true passthrough (where the USB PCI hardware is exposed directly to the guest operating system, allowing the guest to modify the option ROMs, which execute on the host), it should be safe. Do be aware that virtual machines have a nasty history of not being particularly difficult to escape from, so advanced malware utilizing unknown flaws in the program may very well be able escape to the host.


Any comprehensive solutions for binary code protection and anti-reverse-engineering?

The more you invest in protecting your binary from crackers:

the less of your project cost is being invested in adding value for the customer
the more expensive your product becomes, driving away legitimate customers
the longer your time to market, allowing a less conservative competitor to execute faster

Virtual machines are part and parcel of the way IT departments are run now. Avoid running in a VM and you avoid selling your product to part of the market.

Tamper-proofing/Authentication should probably be handled by an OS feature: I know that Windows, Mac OS and many smartphone platforms already support that. My main area of expertise is OS X, which has a "kill" flag such that a process that becomes unsigned can voluntarily suicide. An application can test its own signature, which comes with the proviso that if your app's been cracked you can assume that the test has been changed or removed too.

Obfuscation/encryption techniques are worthless: at some point the CPU has to see the instructions that it actually needs to run, and at this time those instructions can be dumped out to result in the "clean" binary.


First row is guess (leaking by guessing), second timing (for this guess). So best guess, that syscall sysread is at 3a50, that matches reality.


OWASP ZAP: Infinite Redirect Loop infinitely appending a value to a cookie

Sounds like a bug - can you raise an issue for this? https://github.com/zaproxy/zaproxy/issues/new


Secure way of opening web page from iOS without need of logging in

Replay attack is only a concern if you're sending the token over a plaintext mechanism (HTTP), in which case the contents of the page would be available to the attacker as well.  The technique you've described is sound, but you can even do it without needing the DB write.  On the server side, you can simply compute an HMAC across a unique resource id (user id if it's one per user) and an expiration time.  Upon receiving this token, the server can validate it as legitimate and verify that the token has not expired, then present the content to the user.

App calls /getToken?resource=foo
Server generates token: token = foo || now() + 15 minutes
Server signs token: h = HMAC(key, token)
Server returns signed token: token || h
App opens browser to /resource?token=token
Server validates that hash on token is valid for the requested resource at the requested time.
Server provides content to user's browser.


Scraping data from a form submission on another domain

I think you are confused.

  I’d like to build a form on a different site (Site B) which replicates
  the steps and extracts the data from Site A.

That won't be possible because the same origin policy would restrict that. But the vulnerability you talked about has nothing to do with CORS. In fact, there is no security vulnerability to begin with.

  I’m pretty certain that this isn’t possible without API access or CORS
  being configured. Is that right or could you build a bot to do the
  data scraping from Site A to B?

You could build a bot to scrape data from A but there is no need to scrape that data from site B. If you want to scrape data, that is possible and only requires programming. I still don't see any vulnerability, if there is, please tell me in comments or edit the question


Prevent CSRF on public website with no login

First of all, this is not request forgery, since there is no logged in session to take advantage of.  It makes little sense to trick a user into submitting a form on your behalf.

That said, a standard CSRF cookie would do the job.  Generate a unique value for the cookie you already use, on each request.  Then check that it is only used once.


From the paper you quote, additional Symbiotes would both complicate the code rewriting scenario, making disabling them theoretically more difficult; and the Symbiotes could be made to protect one another, making disabling them practically impossible.

The attacker would need to get a precise image of all their entry points and disable them all in one fell swoop, before any of the Symbiote's integrity routines can execute enough to identify the threat (remember, they're multitasked - the attacker possibly isn't, and might conceivably have available for a brief instant the whole CPU power).

To do this, though, the attacker would need to do what you propose - to slowly copy the image for analysis. In the proposed scenario, this is unfeasible, because the code performing the copy would be identified long before it could do anything dangerous. It needs to execute on the victim machine, and that machhine is Symbioted. Copying the image slowly just gives the Symbiote more time in which to notice the copying instructions, while copying fast is going to attract attention to the copying itself.

I'm not too clear on how two Symbiotes might protect one another though - it seems to me that this would require some way for the second Symbiote to become known (and trusted) to the first, which might hint to a possible attack vector. But this might be an oversight on my part: I haven't studied the paper in depth.

A possible way of circumventing security (especially if the Symbiote is not executing very fast) could also be offered by this:

  The SEM injection process requires a handful of parameters specic to
  the target firmware, including a list of randomly chosen control-flow
  intercept points and locations of usable memory. All such parameters
  are computed automatically by a simple single pass analysis of the
  target binary

Ideally the attacker knows the target system and must be thought to have a copy of the Symbiote injector. Therefore, he can run himself the same single pass analysis remotely beforehand, and come up with a large, but finite list of intercept points together with their original content (which the attacker may garner from an original image of the victim OS). Large as it may be, it will be certainly much smaller than the whole victim OS image.

Therefore, as a first stage, he could engineer a "desymbioting" missile composed of an exploit together with the code to restore all those control points to normalcy. Such code would contain a long list of memory locations (easily compressible with a delta strategy) together with the content to poke therein.

If such code were to execute between a Symbiote check and the next, and if it did not trigger inside a Symbiote execution call (which would probably result in a crash), then all Symbiotes in the target system would be rendered inert. This probably poses an upper bound to what a Symbiote may do between two consecutive calls to its Manager - calls must be lean and fast, in order to detect the incoming attack before it has completely deployed.

Using actual numbers from the paper, around 75K functions are deemed to be useable by the Doppelganger symbiote. This is likely to require 75k addresses and 75k DWORDs (presumably) to be defused. 75k addresses in 35 Mb of space are about half a kilobyte apart on average. It is also likely that the hooked areas have a reduced variability - i.e., they are very similar preamble codes. In this case the attacker would need to transfer only about 75k address deltas - around 150 Kb - and maybe the same amount of data. Processing 300 Kb of information isn't going to need a very long time, and a 300 Kb attack package, while awkward, is not unreasonable.

Possibly, the Symbioting operation might also perform some polymorphic surgery on the host OS, to increase the data required by the attacker for a "blind restore". This would require the injector not to be OS agnostic, though. The Manager might choose a large branchless code section between two of its activation points, and replace it with another emergency activation mechanism. The first activation point would set it back to the original code, which would execute, and would be again replaced by the emergency code by the second activation call. If the attacker were to remove all activation points, the emergency code would never get swapped out, the next execution cycle would activate it, and the attack would be thwarted.

While the number of suitable code sections might be comparatively small, the attacker finds himself against a sort of Merkle puzzle - he does not know which code section has been booby-trapped, so he has to process all code sections; and they are large. This inflates the code size requirements for a successful attack, bringing it back towards the unfeasible value of "a copy of the original unSymbioted image".


From a security perspective, it's an advantage. From a management perspective, you have to weigh how much extra effort it might be. If you're worried about losing keys in general, having two (or ten) probably won't change that risk. Some thought into effective key management will pay dividends. If it's not a bother, I'd go for it.
Super-encryption significantly reduces that chance that an attacker will gain access vs single encryption. They would have to exploit vulnerabilities in both encryption methods, instead of just one, which also reduces 'crimes of opportunity' if a vulnerability becomes known for one of those methods. This only works if using two different encryption methods - using the same one twice might be more or less equivalent to using a larger key.
See the Rule of Two: https://en.wikipedia.org/wiki/Multiple_encryption


Best practice pattern for service worker background-sync with CSRF protection

I think that the background-sync could request a new token, apply it
  to the data to send and then send it, and that still be a loop that a
  CSRF attacker couldn't take advantage of, but I'm not certain of that.
  Can anyone confirm this either way?

I'd take this approach. The Same Origin Policy will still ensure that any attacker cannot grab the CSRF token.

  At the moment the CRSF tokens ensure that the request has come from a
  specific page - that's going to have to change for any background
  process to work. Instead there will have to be some kind of CSRF token
  service, so we'll only be able to ensure that the user has previously
  and recently been able to make a request from that service. Is that
  still adequate protection against CSRF?

It is good enough to have one CSRF token per user session. There is little need to go more granular than this and to do it per page. As long as the token is associated with the session and cannot be used for other sessions, then this would mitigate CSRF.

A CSRF token service is a good idea.


If you're interested in understanding methods of protection on a more technical level, there are plenty of articles detailing more in depth strategies to protect yourself from a DDOS attack, such as this one from Cisco: http://www.cisco.com/c/en/us/support/docs/security-vpn/kerberos/13634-newsflash.html

That being said, you may have noticed that even some of the largest service in the world are still affected by massive scale DDOS attacks (Telegram this year, Reddit several times over the past few years). There really is no silver bullet for these kinds of things, although some strategies can include:

Detecting an blocking IP address ranges while the attack is in progress, as schroeder pointed out
Do a packet trace / capture on traffic you believe to be from a few of the offending hosts, and try to find some unique attribute you can use to block the request (i.e. similar user agents, HTTP header data)
Use a service like Cloudflare or Akamai as a CDN - often these services have some degree of DDOS protection built into even their free plans.


How to prevent MITM session fixation attack over plain HTTP upon first request?

Assuming that you always redirect the user from HTTP to HTTPS, you can put your session identifier in a secure HTTP-Only cookie which the server never sends via HTTP.

Actually, in my case the HTTP to HTTPS happens in Apache, so my server code just can't send the cookie to a user with HTTP only.

At least, this will work in the scenario you described in your question. However, I've never heard of a MITM attack that stops at the first request. The HTTPS requests can also be proxied by the MITM so at that point the hacker gets the secure cookie anyway.

As mentioned by StackzOfZtuff, you could force requests to only be done in HTTPS by registering your site with HSTS by adding this HTTP header:

 Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Of course, that means you need to make sure that you have a valid certificate at all time or your site won't be accessible for a while. You may also not want to include sub-domains.

With HSTS, the first HTTP request never happens (at least from browsers that understand that HSTS list. But more and more browsers are now first testing with HTTPS instead of HTTP when the protocol was not specified.)


Why return successfully to non-allowed origins

CORS does not work like you describe. It does not transfer data to the client which can not be transferred without Javascript. Every request which can not be achieved without Javascript is subject to the policy and the browser will check the CORS policy before doing such requests. In detail:

For simple requests any cross origin access is allowed. Simple requests are the ones which could also be triggered without Javascript by including image cross-site, submitting a form etc, i.e. these are XHR requests without special headers or methods.
For any other requests (like XHR with custom header, methods different from GET, HEAD and POST) a preflight request is done to get the CORS policy from the server. And only if this policy would allow the intended requests it is actually executed.

For more details see Mozilla: Cross-Origin Resource Sharing (CORS).

Sure, one might argue that a modified browser might simply ignore the CORS policy and request the content anyway. But, a modified browser might also send a faked Origin header to trick the server into providing the data. In other words: CORS is not a replacement for authentication. It is instead intended to allow cross-site requests using Javascript  without adding additional vectors for CSRF attacks. Before CORS cross-site Javascript XHR was forbidden and insecure ways like JSONP were used.


There are two likely types of certificates they may be asking you to install:

One that authenticates your phone to their WiFi
One that is a trusted root CA which can issue a certificate for any site

The former is more security in that individual users of WiFi can be identified, and linked to the network traffic they create. The latter is the one that permits them to observe the content of your traffic.

Your first task would be to discern whether you are being given an authentication certificate for network layer connectivity or a "trusted root" key owned by the organization for issuing SSL certificates for any site.


Should SSL be terminated at a load balancer?

It seems to me the question is "do you trust your own datacenter".  In other words, it seems like you're trying to finely draw the line where the untrusted networks lie, and the trust begins.

In my opinion, SSL/TLS trust should terminate at the SSL offloading device since the department that manages that device often also manages the networking and infrastructure.  There is a certain amount of contractual trust there.  There is no point of encrypting data at a downstream server since the same people who are supporting the network usually have access to this as well.  (with the possible exception in multi-tenant environments, or unique business requirements that require deeper segmentation).

A second reason SSL should terminate at the load balancer is because it offers a centralized place to correct SSL attacks such as CRIME or BEAST.  If SSL is terminated at a variety of web servers, running on different OS's you're more likely to run into problems due to the additional  complexity .  Keep it simple, and you'll have fewer problems in the long run.

That being said

Yes, terminate at the load balancer and SSL offload there. Keep it simple.
The Citrix Netscaler load balancer (for example) can deny insecure access to a URL.  This policy logic, combined with the features of TLS should ensure your data remains confidential and tamper-free (given that I properly understand your requirement of integrity)

Edit:

It's possible (and common) to

Outsource the load balancer (Amazon, Microsoft, etc)
Use a 3rd party CDN (Akamai, Amazon, Microsoft, etc)
Or use a 3rd party proxy to prevent DoS attacks

... where traffic from that 3rd party would be sent to your servers over network links you don't manage.  Therefore may not trust those unencrypted links.  In that case you should re-encrypt the data, or at the very least have all of that data travel through a point-point VPN.

Microsoft does offer such a VPN product and allows for secure outsourcing of the perimeter.


Are more passwords breached via dictionary/bf attacks or via packet-sniffers/key-loggers?

The likely answer is that neither scenario is the most common, if we measure commonness by the number of affected users.  The all-too-often reported issue is someone gaining access to a machine that has the user/password list in clear text (or encryption so trivial as to be plain text), which breaches the accounts of thousands of users in a single blow.  This is what happened with Sony, Gawker, and Twitter for example.


Will VPN on a mobile device hide location?

It depends on what kind of apps.
If you are talking about apps installed on the device, it changes nothing. If they have access to Location data, that data comes from the GPS subsystem on the phone, not from the internet.
If those apps are websites using Location API, it depends on the browser. If the browser have access to location data from the device and you grant location access to the site, it will be the same as before. If the browser or the site does not have location access, it will show geolocation depending on your IP address, and that IP will be your VPN IP.


How to submit credit card info to a separate server/website (PCI)

The PCI DSS applies to any system which stores, processes or transmits cardholder data. In the scenario you describe above, to the letter of the law, you would need to apply the standard to all systems and networks which make up Site B.

As you are not storing cardholder data in Site B this will at least reduce the amount of work you would need to cover as, for example, as far as I can see, the whole of "Requirement 3 - Protect stored cardholder data" would be N/A.

You will however need to ensure that things like your firewall/DMZ architecture is appropriately put together and managed (Requirement 1), that cardholder data is encrypted in transmission if the connection between Site A and Site B is over an "open, public network" like the Internet.

Picking up your point, and to echo @Rook, SSL will be fine for this purpose (see Requirement 4.1).  You do not need to hash or encrypt the card data at this point. It is only when it is at rest.

Moving through the standard, pretty much everything else will apply, Systems should be hardened (Requirement 2), Anti-virus (if it's a system "commonly affected by viruses") and patch management (Requirement 5), good Software Development processes (Requirement 6) - not forgetting the legendary 6.6, code review or WAF.

Strong access controls (Requirements 7 and 8), Physical security (9), Logging and monitoring (10), regular testing (11) and good information security management (12) will all apply as far as I can see.

Without any of these elements if I were the attacker I would simply target Site B and grab the data either straight off the server as it's input by the customer or as it transmits out of Site B into Site A.

This is actually a common scenario in the payment processing world (think PayPal, WorldPay, etc). "Merchants" (someone taking credit card payments) typically have two choices when they wish to integrate with a payment processor to take credit card payments.

1) They receive the card data themselves, typically through a web form and then POST that data to the payment processor's API for authorisation, etc. This is typically done by the larger merchants. They process the response and update their systems and respond to the customer appropriately.

2) They "redirect" the customer to the payment processor who then takes the card data through a form on their own website so the merchant never sees the card data at all. The merchant is typically then updated as the success of the order by some "out of band" HTTP POST to the merchant's website. The customer obviously has an immediate on screen result.

In option 1, the merchant would be required to achieve full PCI DSS compliance. In option 2 the merchant does not have a need to comply as they are not storing, processing or transmitting card data.

If Site B is not currently in scope of your PCI DSS compliance and you wish to keep it that way, I would suggest you develop a means to take the payment data directly on Site A and Site B just points people that way.

I hope this was useful. I've got a lot of experience with the PCI DSS so would be happy to discuss further. Standard disclaimer though, I'm not a QSA so any decisions regarding scope should be verified with a Qualified Security Assessor before beginning work.


programming language and security threats

The biggest risk in any language is to have developers who do not master the said language. Secure development requires thinking of all "corner cases" and it does not work unless the developer knows what he does at all points. A competent C programmer who does not know Java will do more secure code in C than in Java (and vice versa).

A case can be made that in languages with "strong guarantees", consequences of some programming errors are less dire when viewed from a security point of view. For instance, a buffer overflow in Java leads to an exception and (usually) termination of the offending thread, whereas in C it may lead to an exploitable hole up to a remote shell for the attacker. This makes me a bit less worried when I have to trust developers with Java code than with C code. However, other potential security-related bugs are unchanged between Java and C code (if the code builds SQL statements in a way susceptible to SQL injection, then nothing in Java will protect against that -- to some extent, easy character string handling in Java promotes SQL injection bugs).

Obfuscation is more about maintaining intellectual property than security. It will not prevent attackers from reverse-engineering your code, but it helps in obtaining legal qualification (when using obfuscation, you make it clear, or at least clearer, that you do not want the code to be reverse-engineered, thus making "trespass" more obvious in the eyes of a judge -- but details vary quite a lot depending on jurisdiction). Java bytecode is easier to reverse-engineer than compiled C or C++, but it would be wrong to claim that compile C or C++ is immune from reverse-engineering.


Performance comparison between AES256 GCM vs AES 256 SHA 256

AES256SHA256 uses AES in CBC mode for encryption. CBC mode encrypts a block of data by first xoring the block with the ciphertext of the previous block (or the IV) and then passing this through the block cipher. This means that the encryption of a block is dependent on the ciphertext of the previous block so, encryption of a complete message has to proceed sequentially.

GCM, in contrast, uses counter mode for encryption. It encrypts a counter and xors the encryption of the counter with the plaintext. Since the encryption of each block is independent of other blocks, the encryption of multiple blocks can be parallelized.
The fact that GCM can be parallelized while CBC cannot is probably what is causing the performance difference you are experiencing.


Did Wireshark capture an update of Adobe Acrobat Reader over an unencrypted connection?

I see it's using HTTP instead of HTTPS so yes, it is vulnerable to MITM. However, the software that is downloading the file may be validating it, for example using a checksum or verifying a digital signature.


Is this security scheme using passwords, short-lived access JWTs, and long-lived refresh tokens a good way to secure a REST API?

Okay! Caveat emptor, first off: I’m a rando on the internet, don’t make decisions off this, YMMV, etc.

With that out of the way this seems pretty much fine to me. Nothing seems out of the ordinary here. The main thing I’d check is securing the secondary endpoints, like /refresh. Make sure that one can’t be fiddled with, for instance. And make sure you test all of this thoroughly in your test suite.


I think that having sensitive data (whether it is the password, or derived key, etc) in memory is not something that most systems deal with.

That being said, here are several possible mitigation methods for protecting private data in-memory. This could apply to a variety of subjects, Server, Mobile or Desktop. The principals are the same. I'm also not sure which attack vectors you are most interested in. (virus, physical attacks)

An obvious first step would be to disable swap which is a feature that takes less used 'pages' of memory and writes them to a space on the hard disk. It would be fragmented, but quite possible for the attacker to get data with this method.

It is possible that some OSes provide a means to store specially marked memory that is forbidden from being stored in swap. I've never researched it though, and I am sure it is more complex than your typical runtime variable. If you did it this way, you would no longer need to disable swap on the whole machine taking the performance hit associated.

@Stephane comments that Windows has an option called CryptProtectMemory which encrypts the memory. I think this is clever as that way only the key would have to be forbidden from swap, instead of each individual piece of sensitive information.
As for the Memory itself (swapped or not), if you are logged in as root or as the same user account the process is running under, there is a means to dump all memory for that given process. Many of the high-level programming languages provide this functionality internally with the same user account conditions.

Android solves this problem by providing each app with their own user account in the OS, which gives many additional benefits.
Server environments often have services segregated into alternate user accounts to help contain potential breaches, both from a memory and from a file-system storage perspective. (never run a public-facing service as root!)
In a traditional desktop environment, there's not much you could do to secure processes running in the same user account.

The last possibility would be a special hardware module (either to store the data, or an encryption key for the data) which is separated from the main operating system. I would suggest taking a brief look at Trusted Execution Environment (TEE) and/or Secure Element (SE). See Android Keystore System.

There is also the more extreme method of using a completely separate (small) computer, i.e. Raspberry PI.

Related: https://security.stackexchange.com/a/36636
Specifically to your example of a Master Password, you could of course not store the overall master password, but just final password that was extracted from the store. This way the user has to re-enter the Master Password when visiting a new site.


The question is how I can be sure that my official ID will not be used by someone in the company.

You can't, there is no way to guarantee it will not be used. I know of systems that will send your data to a third party to determine if the passport and selfie photo are a match or not (bank account creation process).

However, back in the day when these services did not yet exist, a photo copy was made of your ID, hoping they'd store it in a proper way. So in a way the current services should be considered less prone to human errors.

Also, before these internet services, what kind of guarantee did you have an employee would not use your photo copied identity?

When comparing back then with the current way of working, the risk level can be considered less. This assumes the current API's and/or web services are considered sufficiently secure.

  What could be a good solution in this case?

I do the same thing when I have to send a photo copy of my ID. I edit the scan and add a date and the company name I am sending it to (this way I know who leaked it when I find a copy of it myself)

One idea I have (which is not fail safe) is add metadata to the files that are sent to these services.

  ... but such services require unchanged scans and photos.

Do they really? From a technical perspective this is not really required. There is a difference between what they (as the company) want and what they (the company) need.

It could also depend on the country's laws about storing PII data.


Is it alright to put .htpasswd in the protected directory if there's just one user?

By default, Apache is suppose to deny access to .htaccess and .htpasswd files. For some weird reason, you have the ability to disable it (accidentally or otherwise) in your configuration. If you have disabled this protection somehow (or if, for some reason, it wasn't setup in the first place), then any malicious attacker could exploit this to download the .htpasswd file.

Normally the suggestion is to have the file outside of your web directory, preventing it from ever being served to a user, while still giving Apache access to it.


Does malware persist after wiping hard drive and reinstalling OS from manufacturer disc?

Yes, and there have been cases of this being stored in different areas on the computer one classic example can be found at the following URL:

http://www.pcworld.com/article/2948092/security/hacking-teams-malware-uses-uefi-rootkit-to-survive-os-reinstalls.html

This article goes into a little more detail on how this works

http://arstechnica.com/security/2015/02/how-omnipotent-hackers-tied-to-the-nsa-hid-for-14-years-and-were-found-at-last/

Another interesting area is having malware stored in video cards, although this may not be persistent in the future this type of attack may become very interesting.

http://arstechnica.com/security/2015/05/gpu-based-rootkit-and-keylogger-offer-superior-stealth-and-computing-power/


IP, and TCP/IP pre-dates the OSI model. Layers 1-4 of OSI almost map to the network and TCP/IP stack (which TLS sits on top of) but if you keep trying to explain one in terms of the other you're going to become lost; there are at least 3 session layers in a HTTP/2 application, usually 4 and sometimes more.


You should check this github repo: https://github.com/jhaddix/tbhm

  Welcome! This repo is a conglomeration of tips, tricks, tools, and data analysis to use while doing web application security assessments, and more specifically towards bug hunting in bug bounties.

Make sure to also check the video :)


How do authentication system know if I am reusing a password? How is this secure?

In a well design system, your actual password is never stored. Instead, a one-way function, called a hash, is used. Hash functions are mathematically designed so that there is no one-way relationship that allows you to do the function in reverse and get back the original input. You can get a basic understanding from this article.

In the backend, only the hash is stored. In the normal application logic, when the password is received from the user at login, it is hashed the same way as when the password was created. The stored hash value and the hash of the password typed at login can then be compared.

Using this design, we compare these password substitutes and never store the password. As a result, if someone found the hash in the backend, they would not have your password. They could not abuse the normal login flow with just the hash because they cannot reverse it. If the IT admin or a hacker only had access to the password hashes it would not be enough to do anything directly.

*Note: Password hashes cannot be reversed, but you could calculate values for given input passwords and see if the match. Salting and other techniques can help to make this more difficult. Read the article I linked to above for an intro to the concept

In terms of password history, you don't need to store the passwords, but you can store all of the hashes as well. When you are asked to enter a new password, that password will be hashed and then that hash will be compared to all of the hashes in the history list. This means that no old passwords need to be stored directly, so no one can get to them.

It is also possible to use the hash history to test for passwords which are similar to those used in the past without knowing the plaintext:

For example, if you entered a password of "DogFood" you could also generate lots of variations using some algorithm so you would get something like {"dogfood", "DOGFOOD", "dOGfOOd", etc. }. The algorithm may try all sort of modiciations like character replacements, one off keys, check for incrementing numbers (e.g., if you do "password1" it will add "password2", "password3", etc). Then for each variation you also calculate the hash. If the hash of the original password or any of the possible variations match a hash already in your history then it is too close a match and will not be allowed.

The key point is that comparisons are never with the actual value, but with the hashes computed.

One last thing, it is possible for a system to "encrypt" instead of "hashing" passwords. In this case there is a higher likelihood of the actual password being exposed. However, hashing is used 99.9% of the time and password encryption is only used for specific needs or by a bad software design choice.


Feedback for self-signed certificates setup for custom product auth?

The use of TLS makes sense. The use of self-signed certificates makes sense as long as you properly deal with the servers certificate at the client side. This means that

The trusted self-signed certificate properly validated for example by using the fingerprint (pinning) or the certificate itself. This means also that it is known before the first connection is established by the client, so that already the first connection can be validated.
The trusted self-signed certificate is only trusted for connections to the specific device. This means especially that it is not imported as a generally trusted CA into the browser. Otherwise it could be used to intercept other connections in case the private key of this certificate somehow gets known to the attacker.
A working process is established how trust into the certificate can be revoked in case it gets compromised and how it can be replaced when it expires or gets revoked.

Your question does not provide enough detail to decide if these requirements are satisfied by your design.


At the moment there is no way to easily work out whether to trust specific docker containers.  There are base containers provided by Docker and OS providers which they call "trusted" but the software lacks good mechanisms as yet (e.g. digital signing) to check that images haven't been tampered with.

For clarification to quote the recently released CIS security standard for docker section 4.2

  Official repositories are Docker images   curated and optimized by the Docker community or the vendor. But,the Docker container image signing and verification feature is not yet ready.

  Hence, the Docker engine does not verify the provenance of the container images by itself.

  You should thus exercise a great deal of caution when  obtaining container images.

When you get into the world of general 3rd party containers from Docker hub, the picture is even trickier.  AFAIK docker do no checking of other peoples container files, so there's a number of potential problems

The container contains actual malware.  Is this likely, no one knows. Is it possible, yes.
The container contains insecure software.  Dockerfiles are basically like batch scripts that build a machine.  I've seen several that do things like download files over unencrypted HTTP connections and then run them as root in the container. For me that's not a good way to get a secure container
The container sets an insecure settings. Docker is all about automating set-up of software which means that you are, to an extent, trusting all the people who made the dockerfiles to have configured them as securely as you would have liked them to.

Of course you could audit all the dockerfiles, but then once you've done that you'd almost have been better just configuring the thing yourself !

As to whether this is "worth the risk", I'm afraid that's a decision only you can really make.  You are trading off the time needed to develop and maintain your own images, against the increased risks that someone involved in the production of the software you download will either be malicious or have made a mistake with regards to the security of the system.


Why does productsign use SHA1 instead of SHA256 to sign the pkg?

The problem is not how to sign the package but to you check for the signature. It turned out to be a kind of bug of the pkgutil tool which only shows the SHA256 signature on macOS 10.15 (Catalina) while on macOS 10.14 (Mojave) the same tool for the same package only shows the SHA1 signature.

So even if the signature was present it wasn't shown by pkgutil.
Furthermore in this blog the author suggest to use spctl -a -vv -t install package.pkg to validate a package because spctl can also check for notarization.


Is OpenLDAP version 2.4.24 at risk and what site should I check for known vulnerabilities with the used version?

The search functionality in cvedetails.com does let you search on version, but the output is not very handy.

Your best bet with the site is probably to just take the page you linked to and grep through for 2.4.24 to get the associated vulnerabilities.


Storing lots of passwords that different levels of employees need access to

First off, for as much as possible you need to switch over to something like Windows Active Directory or using LDAP* for internal permissions.  That way, users get permissions based on a central repository, don't know other users passwords, and you can audit who is able to - and who did - access what.

I'll assume you aren't in a regulated industry (if you are, you're in real trouble).  Even then, your company's current setup shares all the passwords with Dropbox, anyone who has access to Dropbox data or backups, and potentially with any company that later merges with or acquires Dropbox.  This may or may not be an argument anyone cares about.

Changing passwords is a big deal, and any time anyone leaves, you SHOULD be changing passwords - why does someone not employed or under contract have access to corporate resources?  It's even worse if they left under less than amicable circumstances.

After you're done with the AD or LDAP integration, there will still be systems that aren't integrated.  For those, I'm a big KeePass** fan.  Employees can have a "personal" KeePass file, which is their primary, and holds person-specific accounts - which should be used as much as possible, so they can be disabled when people leave and so actions can be audited

You SHOULD monitor for, and take serious action when you see employees sharing passwords.  This is a very common practice in small unregulated companies, and it causes problems later (audits failed, clients asking hard questions on their own audits, future regulation, and again the cost of changing every password any ex-employee knows).
If your employer really loves Dropbox, there is KeePass integration available, as well as FTP, SFTP, etc. integration.

Ask them what their plan is for times Dropbox is inaccessible (being DDoS'd) or suddenly goes out of business (if Enron, Lehmen Brothers, and Lavabit can vanish overnight, so can Dropbox)

Employees may also have shared KeePass files if absolutely required - it does a good job of handling a few people opening and modifying the same .kbdx file simultaneously, merging the updates, or you can use the Synchronize command.  The passwords and keyfiles used to open these shared KeePass files should be kept to as few people as possible, the contents should be kept as minimal as possible, and you again change passwords and keyfiles whenever someone that knows them leaves.

Again, set up individual accounts at every point that can be done.  When you have to investigate something (call it a production problem, or maybe fraud), this is critical.
For any shared KeePass databases, use both a randomly generated keyfile if management agrees to it, but also long (35 character or more) passwords generated randomly by KeePass itself; employees keep the shared passwords in their personal KeePass database, and the passwords MUST be so long and random that it's honestly burdensome for employees to hand-type them.

That way, there's no incentive to write it down; it takes forever and it's a pain to type anyway.
High ASCII characters can also be used, like the copyright symbol or accented characters, making it even more difficult for employees to get in the habit of using shared superuser accounts without going through their own KeePass document.

*For a linux example, see the question "how do I configure my RHEL5 or RHEL6 system to use ldap for authentication?"

** When you set up your KeePass database, or afterwards if someone else does, make sure to go into File, Database Settings, and click the button for the "one second" number of rounds.  Increase it from there as you see fit, but just doing that even on a very slow machine increases your security significantly - I usually use millions to tens of millions of rounds, since a second or five doesn't matter compared to the speed savings of the auto-type feature.


First, why must an SSH server have at least a maximum packet size of 32678 bits?

Because it is IETF standard (RFC 4253) and if you want to stay inter-operable with other applications using this standard, you should follow it. If you choose different lover value, sooner or later, you might encounter unexpected errors.

Saying other tools do not support such a large packet is not true. OpenSSH us using max packet size of 256 K.

  Second, would it be ill-advised to ignore the standard, and support a lower maximum packet size?

Well ... you can try that. If the implementation is made in the way that there is a single constant which you can later change, you will implement it and see what happens for your clients and your use case. It always depends on what compatibility you are aiming. If you want support few clients you operate, it is probably ok, but if you aim for public service with unknown clients, it might be a bad idea.


Is it possible to sniff MAC addresses from a client that is not connected to an AP?

802.11 devices send probe requests to identify if a given network is nearby. Probe requests still contain standard MAC headers - which would contain destination and sender address fields. The destination address would be set to the broadcast address ("ff:ff:ff:ff:ff:ff") but yes in normal client operation you would expect the client to fill their own address into the sender address field.


Why are my plastic credit card and activation code sent separately?

Many low level crimes are ones of opportunity, not planned out attacks.  By separating the two needed pieces of mail in time, it forces the attacker to intercept the same person's mail more than once.

This prevents a mail thief from simply walking up to homes and looking for credit cards and activating them all in one step.  Now suddenly the thief has to go back to the same house, or intercept the same person's mail at least twice, and possibly multiple days in a row.  That takes time, effort, and additional exposure.


Use passphrase-protected private key to validate user passwords

Ok, let us see what is involved in both case.

Standard salted hash

On password creation, user gives the clear text password. It is hashed with a secure salted algorythm and only the hash is stored

On further logins, user gives the clear text password. The salt is extracted from the password store and the hash are compared

Security heavily relies on the quality of the hashing algorithm, but is a strongly documented point, and on the intrinsic quality of password - read entropy of password generation
Password is used as the password for a private key

It is basically the same process, the only difference is that the hashing algorithm is replaced with an attempt to unlock a password protected key. It now depends on the encryption algorithm used to encrypt the private key. That is also a strongly documented point.

That means that you have only changed a hashing algorithm with an encrypting one. BTW the original hashing algorithm used in old Unix system was based one the encryption of an all zero bits byte string with the user password with DES(*), not far from your proposal.

TL/DR: it will just depend on the hashing algorithm and the encryption algorithm used to encrypt the private key

(*) It is in fact a bit more complex because the crypt operation was repeated 25 times and perturbated with salt (ref.) - credits to @RoyceWilliams for the precision.


What is the hack attempt going on when I see: did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA

SMTP expects commands in the following sequence:

HELO or EHLO servername
MAIL FROM: <address>
RCPT TO: <address>
DATA

Though technically instead of MAIL FROM, the server could send EXPN, VRFY, or ETRN, though nobody ever does.

Apparently your server got the HELO or EHLO greeting, but then nothing after that, or something after that that wasn't expected.

Often this comes from monitoring agents or other scanners who aren't interested in actually sending mail, but rather just testing to see what's listening. Also, it's quite likely that they're attempting to exploit some old vulnerability, which is (correctly) simply being interpreted as garbage and terminating the connection.

Typically when a server takes some unusual steps (such at prematurely terminating a conversation) it will make a log entry noting the fact, just in case you need to debug it later.


What you're looking for with cracking WPA-PSKs is handshakes (clients joining the network), so the exact amount of time that you'll need to wait depends on how busy the network is.

As a tip you can run airocrack-ng on the cap files whilst you're capturing traffic and see if there are any handshakes listed for the network that you're interested in.

Also another way to speed things up is to lock airodump-ng onto the channel that the network you're interested in is using (using the --channel switch) as that way it won't hop around all the channels and you'll get more traffic that you're interested in.

Additionally if there are clients on the network but there's not a lot of joining activity you can use a deauthentication attack to speed things along.


What are the main issues and best practice security controls when exposing SIP and H.323 to the Internet?

Avaya's quick two-page checklist is broadly vendor neutral. Key first steps include:

H.235.5 for H.323 signaling encryption
SRTP* for H.323 / SIP media encryption (10 bytes overhead per packet)

Standalone AES encryption can also be used for H.323 media
encryption

TLS for SIP signaling encryption
SRTP for voicemail interaction
TLS for adjunct communications
AES encryption for configuration back-up
Note, network regions can be created to segment phones that don’t support
encryption from phones that are capable of encryption

In order to set it up so that Security and QoS is maintained, you will need a firewall set which is H.323/SIP-aware. From this SANS paper:

  Many of the protocols used with the H.323 suite use random ports causing problems securing through firewalls but may be able to be mitigated by using direct routed calls. Since the ports required for H.323 are not set, a filtering firewall would have to have all possibly needed ports left open. Therefore, the firewall would need to be H.323 aware allowing communication without opening up the firewall to other traffic. A stateful firewall and/or application firewall is required to ensure consistency of the characteristics of connections.

There aren't a huge number of firewalls which support SIP/H.323 well, but the usual stateful enterprise ones like Juniper, Cisco and Palo Alto seem to work.


Is Lock-a-Folder a secure and reliable way to encrypt information?

Considering that Lock-a-folder is no longer supported by its developers, I would definitely say NO, it is not a safe option for securing data.

  Developer have abandoned this Project and will not reply to any
  queries. You can use this code at your own risk. Anyone interested in
  further development of this project can clone or contribute. https://code.google.com/p/lock-a-folder/

You'll be much better off with a more well known file encryption utility, like one of Truecrypt's successors (like https://veracrypt.codeplex.com/) or GPG.


Is there any way to bypass .htaccess PATH restriction (in URLs)?

While what you've listed will work, mod_rewrite is not really an access control tool.  Apache provides you with tools specifically for denying access, which operate after the file names have been canonicalized (converted to the form that will be used to open files on disk).  Using something like this is the intended way to block access to myfile.txt:

<Files myfile.txt>
Order Allow,Deny
Deny from all
</Files>

Your backslash example should make no difference -- the user will just get a 404 error, because a file named my\fi\le\.txt will not exist.  (Backslashes are a perfectly legal character in UNIX filename, and you can send them, although most browsers will convert them to forward slashes because Windows users.)


Why are Android permissions granted in groups?

They don't want to scare users from using apps - if an app needs to use the phonecall ability it will probably need some more permissions for regular use (getting too much permissions requests from an app will concern users).
So to compensate - they put the permissions in groups.

This also effect the usability of the OS - the overall UX is better with less permissions requests:
If you look at what is written in developer.android.com about providing explanation for permissions:

  Keep in mind that you don't want to overwhelm the user with explanations; if you provide too many explanations, the user might find the app frustrating and remove it.

In paraphrase: they don't want to overwhelm the user with permissions requests  - and it also effects the OS ability to explain the permission riskiness to the user: "access contact" instead of read/write contacts and get accounts. Not every user will understand what is SIP - but every one knows what is a phone call.


Security implications of exposed Dropbox API key and secret

... the Dropbox PHP SDK requires you to put your API credentials in a
  JSON file that might be publicly available if the SDK code is placed
  within the DOCUMENT_ROOT directory.

This is definitely not true. I think some of the example apps use a nearby JSON file to store various credentials for convenience, but there's nothing in the SDK that requires you to do that. (You could store the JSON file elsewhere, and the constructor for AppInfo takes a key and secret, so you can manage them however you want.)

For most apps it's probably not a big deal to expose the app secret, but I would still discourage developers from doing so.

To learn more, look around for discussions about exposing OAuth consumer secrets. Notably, mobile apps typically do expose those secrets (at least in OAuth 1), so there's been a fair amount of discussion of the security implications.


Sending Probe Request Frames | Receving Probe Response -- Scapy

That's because you didn't include the "Dot11Elt" layer, try this:

RadioTap()/Dot11(type=0,subtype=4,addr1="ff:ff:ff:ff:ff:ff", addr2="00:11:22:33:44:55",addr3="ff:ff:ff:ff:ff:ff")/Dot11Elt(ID="SSID", info="")

or:

RadioTap()/Dot11(addr1="ff:ff:ff:ff:ff:ff",addr2="00:11:22:33:44:55",addr3="ff:ff:ff:ff:ff:ff")/Dot11ProbeReq()/Dot11Elt(ID="SSID", info="")


Is a single page application naturally breaking the same-origin policy?

If you want to avoid making cross origin requests, host your frontend and your API on the same origin. If you host them on different origins, by definition you must make cross origin requests.

And if you do have to make cross origin requests, just use CORS. JSONP is an ugly hack that should be avoided. It was used back in the day in situations like this, because there was no CORS back then. Then CORS was developed to deal exactly with the kind of situation you describe.

So asking how to make cross origin requests without CORS is sort of like asking how to hit a nail without a hammer. Just use the hammer, that's what it's there for!


Could Common Vulnerabilities and Exposures (CVE) be used by the US government before being released?

It is very clear that governments (not just the USA) do indeed make use of known vulnerabilities. I doubt that, at least the majority, of CVE's are deliberately delayed other than the delay that is typically offered to the vendor to allow them to fix the issue before public release. CVE's are reported from a wide variety of sources and wouldn't easily be intercepted by governments.

However, there is a rather bigger issue in that there are 3rd parties who offer vulnerability bounties of $m's for provable exploits. These are far larger than the bug bounties typically offered by vendors. The vulnerabilities are often sold to governments and not released publicly.


Store password in Public Domain using files and md5sum

Advantages over a password manager: Little to none.

Security problems:

Your password generation technique would be logged in command history.
Any file access mechanisms would record access to these files every time you log in.
Your password would be visible on screen every time you needed to use it.
If any files change without your knowledge, your password is lost.


IP spoofing is the term used for forging an IP address, however it's very hard to accomplish with a SMTP connection as it requires an established TCP connection. IP address spoofing works as an attack when you don't need traffic coming back to the sending host. Using an analogy, if I send a letter to an address with a return address other than mine I will not get any response - it will be sent to the return address on the letter. I would not be able to form a correspondence with anyone if I'm forging the return address.

SMTP uses TCP, a protocol that establishes a connection between two hosts and controls the flow of information between them. A system trying to establish a connection using a spoofed IP address will not be able to set up a TCP connection as packets from other host will be routed to a the server which actually owns the IP address.

If someone was able to insert themselves in a point in the network between the two authentic servers they could use Network Address Translation to change the source IP address of packets from a server they control and set up a TCP connection, however this is very sophisticated and extremely unlikely. In any case you could defeat this by using public/private key pairs to verify the sending host. You don't need to be concerned about someone spoofing the IP address of your email server.


Are these claims about public WiFi accurate?

Is my analysis of public WiFi completely off base?

TL;DR - You analysis is not off. You are correct.

  Does my bank have a
  good reason for making these recommendations to (presumably lay) users?

In my professional opinion, your bank is in error. While using Starbucks is safer than connecting to someone's home wifi, this can lull a client into a false sense of security. WPA-2 encryption has been proven to be vulnerable, and WEP and WPA encryption are child's play to crack. Once on a wifi network, a simple packet sniffer can capture all sorts of information unless other hosts are using a VPN.

  It seems like it would be relatively easy to set up a fake Starbucks access point.

You are correct. They're called evil twin AP's. Besides hiding the hardware, they're relatively easy to set up and the kind of person who could detect it is not the kind of person to use free/public wifi.

  Attempting to contrast "unsecure wifi networks" (presumably unencrypted?) with "known sources" seems to be missing the whole point of the risks of public WiFi, as well as comparing orthogonal concepts.

The only difference between a known and unknown network is familiarity. Technically speaking, knowing the barista does not make one's network more secure. Again, you are accurate. Your neighborhood friendly barista probably doesn't know if his/her network is compromised, so having the warm fuzzies about connecting provides no security.

Finally, your point (which was not chronologically last but an excellent summation anyway)

  As a security-minded person, my advice to friends who ask has been to never connect to WiFi networks where you don't know the person responsible for it and all the other people who are connected without (1) a well configured firewall and (2) tunneling all traffic through a trusted, encrypted VPN. (Starbucks WiFi would of course fail this test.)

You are correct in your advice. Always use a VPN on Wifi, and ensure you have some sort of AV if you're running windows. (Linux machines, like the one I'm writing this on, have different set of "rules" for firewalls and you can simply change iptables).


The security of this depends on how exactly you do the encryption. If you are using CBC-mode and no integrity checking, then I see a weakness that could allow one user of your app to impersonate another user:

The attacker gets legitimately issued a token for their own Facebook account. They then wait 48 hours so the token is invalid. If they present this token to your server, they get issues a new token. Crucially, in this request, only the Facebook ID matters - the Facebook token is irrelevant.
If the encryption does not have integrity checking then they can tamper with their token to change their Facebook ID. If the encryption uses CBC-mode, then this is fairly trivial. When they present the tampered token, they then get a legitimate token for the other user's Facebook ID.

You can fix this by using integrity checking as well as encryption. In fact, you may actually want to ditch the encryption and just use integrity checking. You have SSL to encrypt everything on the wire anyway.

Another consideration: how exactly do users login with Facebook? You should use the "Log in with Facebook" button (iOS info) rather than presenting a web page directly within your app.


Why is GPG file encryption so much slower than other AES implementations?

Let's try...

First, I create a 500 MBytes file full of random bytes:

dd if=/dev/urandom of=/tmp/foo bs=1000000 count=500

then I encrypt it using GnuPG, measuring the time taken by that process ("keyID" is the UID of the public key I am using):

time gpg -r "keyID" --cipher-algo AES256 --compress-algo none -o /tmp/bar --encrypt /tmp/foo

Total time on my machine (Intel i7 at 2.7 GHz, 64-bit mode, GnuPG 2.0.22):

3.77s user 0.55s system 99% cpu 4.328 total

so an encryption bandwidth of 115 MBytes per second: that's not so bad ! Now let's try again, but this time without deactivating the compression (i.e. let's remove the "--compress-algo none" options):

20.99s user 0.79s system 98% cpu 22.038 total

which is 5 times slower. So there you have it: it is not the encryption which is "slow", it is the compression (although more than 20 MB/s can still be decently fast for many usages).

115 MB/s is consistent with a "portable" implementation of AES. Code which uses the specialized AES opcodes (which are available on my i7) would be faster, up to, say, 300 to 400 MB/s (though AES-NI opcodes have a very high throughput, they also have a non-negligible latency, which means that the best performance requires parallel processing, i.e. CTR mode; but the OpenPGP standard mandates CFB, which is sequential).

Anyway, since a good mechanical hard disk tops at about 120 MB/s, while a very good Internet access (optic fiber) will be below 10 MB/s, one can say that 115 MB/s of raw encryption speed is sufficient.


The attacker already knows the capacity of all your buffers. This is the normal basic assumption: buffers in your software are defined by the software itself, which exists as source code, executable, backup copies, and in the heads of the designers. The same software may have been purchased by the attacker, and reverse-engineered; or the software could simply be opensource. Software cannot be considered to be secret in any way, because there are way too many ways for outsiders to learn that secret software.

Suppose that you run some software on your server, that expects from connected clients a user name and a password. The software will store the received data into in-memory buffers before processing that information. Suppose that the buffers are apt at receiving 200 characters each. The attacker also knows that (see above). So far so good.

The problem is not that the attacker knows the size of your buffers; the problem is when the attacker supplies more data than can fit into the said buffers, and the software, erroneously, tries to push the data into the buffer even though it makes no sense. This is the buffer overflow: the stupid, gullible software is induced into trying to do something nonsensical, and the data spills over other data elements in the machine RAM.

Some programming languages, in fact most of them except prehistoric languages like C, systematically check array accesses and thus detect the buffer overflow attempt even if the developer failed to include the necessary checks. This does not solve the issue (the problem being that the software still want to do things that make no sense), but at least it contains the damage (the offending process is swiftly killed, and that's the extent of it).


Choosing between SSH and HTTPS for executing script using McAfee ESM Nitro

It depends a lot of how your infrastructure looks like and how much time and money you want to invest (or already have invested) in your security infrastructure.

On one hand, SSH is easy to deploy, require authentication by default (so less room for error) and can be made quite secure very easily. The downside is that the security aspect doesn't scale too well: key management in larger environment is complicated and the default fall-back (accept any key from server) is insecure. Client key management is also an issue.

On the other hand, you need a more effort to deploy HTTPS securely and have the same level of security that what you'd obtain from SSH (Assuming you're using key-based authentication). The advantage is that it's easier to scale: you can use a private PKI for managing keys easily and, once you have a working configuration, it is very, very easy to securely replicate it across as many systems as you want.


You are going about it all wrong. Why will you need to send the USER_ID over a GET request to retrieve the secret questions and tokens like you mentioned?

You probably store the reset tokens in a table in the database with a foreign key linking it to the user's data stored in another table. You can simply parse the token sent using GET and retrieve all the information you need about the user.

Also, the way you describe your process isn't very clear. You should ask the user to input the secret question before sending out the password reset link. There is no point in doing it the other way around and not requiring any validation to trigger a password reset can be very annoying for a user if he gets endless password reset request.


Some good answers here, but I think some points were missing:

Automatic tools finish a lot faster than manual testing, by orders of magnitude.
Automatic tools cover the breadth, but you need manual testing for depth. (Breadth both in range of attacks/tests, and in probing all interfaces / lines of code).
Autotools are great for the common low hanging fruit, but if you need to step up the level of security you'll need to go deeper manually.
Manual testing cannot possibly cover every bit of the system (whether it's lines of code, decompiled assembly, web pages and parameters, web services, etc), whereas autotools are great for that.
As @Andreas said, sometimes there is a complex vector, that autotools cannot possibly imagine, but will be obvious to an expert.
Autotools cannot test for business logic flaws, they hunt the technical flaws only - and the more common ones, at that.
Manual testing is not consistent.
Manual testing depends on the skill of the individual tester (oh, the horror!!), but you really need to know what you're looking for.
Likewise, with manual testing you cannot get regression testing.
Autotools are automatically updated with the newest exploits, but a human usually won't remember all the vectors he read about two years ago...
On the other hand, autotools will only get updated once every while, but a human can learn about a spanking new technique and implement it the very next day.
Autotools usually include a very high percentage of false positives (from 30% to over 90%, depending on the methodology and choice of product).
Autotools usually come with a decent reporting suite.

Bottom line? They both have a place, and should both be used in the correct context. For low-quality apps, first start by fixing everything the autotool can find, and don't bother with investing in a proper manual review just yet. When you raise the security level, and gotten rid of the low hanging fruit, go the distance and perform an in-depth manual review. And, when you're doing manual testing - first step, is running the autotool, filter the results, THEN begin the real testing.


TPM just stores the AK (authentication key) that is used to decrypt the DEK (Data encryption key) internally in drive. Then DEK is used to decrypt data.
From Overview of Encrypted Hard Drives and BitLocker (eDrive) that is actually implementation of TGC OPAL2:

Strong security based in hardware: Encryption is always "on" and the keys for encryption never leave the hard drive. User authentication is performed by the drive before it will unlock, independently of the operating system.

Another good source of information is at:
https://wiki.archlinux.org/index.php/Self-Encrypting_Drives#Set_up_the_drive
About vulnerabilities
I own Samsung 850 EVO SSD and I really wanted to find the answer how bad it is, So I have been searching information about the flaws all day. Everyone claims the Samsung's SSD is not safe. So I have read the original whitepaper:
Self-encrypting deception: weaknesses in the encryption of solid state drives (SSDs)
There is particular table about security flaws:

Vulnerabilities are related only to ATA Security and impact 'Depends' for Samsung's ones.
ATA Security:

...
The ATA password may be cryptographically bound to the DEK. This depends on the value of the MASTER PASSWORD CAPABILITY bit during the ATA security setup.
...
In case the MASTER PASSWORD CAPABILITY bit is set to Maximum, the decryption key is derived from slot 502. Otherwise, the key is stored in plain-text format in slot 465, and slot 502 and 503 are used for password validation only. Thus, allowing the encryption to be bypassed.
...

But in attack strategy they mentioned for OPAL (Bitlocker + HW Encrypted Drive):

(850) Since TCG Opal implementation is mostly identical to its predecessor, no weaknesses have been identified.
(840) If ATA security, with the MASTER PASSWORD CAPABILITY bit set to Maximum, or TCG Opal is used, then the DEK is cryptographically bound to the password.

That means it can't be bypassed without the AK (in your case stored in TPM).
I am a bit surprised that even Samsung recommended use of 3rd party software encryption as mitigation for the vulnerabilities even their disks should be fine if they are not using ATA Security.
What I wasn't able to find is information if you can use ATA Security operations if disk is in OPAL 2 (Encrypted drive for Bitlocker) mode.
I think it can't be used because the mode is chosen once during setup of a drive and it is not easy to reset it - actually reset the DEK for which the PSID label is needed... But I am not sure.


The page you refer to has the following code:

Hello, guest!

 should result in
Hello,
 which should in your opinion result in the script getting executed.

But this is not the case. The documentation of Element.innerHTML explains why:

  HTML5 specifies that a


Impersonation of TLS host with own wlan network

Idea: Setup a local device (lets call is rasp) which opens a wifi hotspot. The MCC should then connect to the rasp. The rasp answers with a certificate from the public server mcc.com, but sends the modified JSON data.

Your host rasp cannot impersonate mcc.com by providing the same public key. You would need the server's private key to do this. Therefore, if there's any checks on your IoT device towards verifying the TLS endpoint is valid (validates against a CA or uses certificate pinning), your idea will fail. Otherwise it might just work regardless of you using your own certificate on the fake server.

DNS is easy to tamper with since you control the local network and, as I understand it, traditional basic DNS is used. Ultimately you don't even need to touch DNS, you just need to intercept the TLS request and forward it to your own server.


PCI compliance is not insurance.
It is not a real measure of protection.

I sum up the value of of PCI compliance in my well-known eponymous law, AviD's Law of Compliance:

  PCI compliance reduces the risk of the penalties of non-compliance.

In other words, much like how paying taxes is a requirement but does not necessarily entitle you to any specific government benefit - you have to be compliant. And if you're not, you will have to pay a fine. But this does not necessarily help with preventing breaches or responding to them...

As I answered in Vulnerability scanning applicability for PCI DSS, compliance is not about security.
As the other answers here mentioned, you need to implement security controls and secure features aside from the compliance. If you get breached, you still have fallout from that.

However, being compliant in the event of a breach does mean that you won't be getting a non-compliance fine. (See AviD's law above...) You'll need to pay any other costs, such as damages and repair costs, but at least there won't be a fine (well, at least not from PCI - other laws and regulations may apply).


Java org.xmlpull.v1.XmlPullParser and XML External Entity (XXE) Processing Attacks

Well I can answer my own question now, at least in part.

The application I was examining has a default instance of XmlPullParser with only FEATURE_PROCESS_NAMESPACES disabled.  I was able to get the Billion Laughs entity attack to work.  My issue what I was not putting the entity in the right child element of the expected XML response.


Without checking too deep, I would say WP is the top risk in that list. I assume its updated, so you should check its settings and the plugins you have installed.

Check this article: https://isc.sans.edu/forums/diary/Wordpress+Pingback+DDoS+Attacks/17801

  Sucuri detected an interesting "reflective" attack using the
  Wordpress Pingback feature to attack web sites [1]. Unlike other
  reflective attacks that use UDP services like NTP and DNS, this
  attacks uses the Wordpress Pingback feature.

  The intend of Pingback is to notify a site that you link to about the
  link hoping that the site you are linking to will return the favor.
  Some systems automate this and maintain automated lists linking back
  to sites that covered their article. In order to implement pingback,
  Wordpress implements an XML-RPC API function. This function will then
  send a request to the site to which you would like to send a
  "pingback"...


Can your iphone be unwittingly jailbroken?

Jailbreaking from the browser used to be possible. Older iPhone OS's will still have this potential vulnerability. That being said, jailbreaking via a browser has now been outdated and patched by Apple. I believe it was patched in iOS 5.0 and has been patched since. So older iPhone users (pre-iOS 5.0; which are few and far between) might still be vulnerable and potentially a malicious website could exploit this. As of now, all jailbreaks (to the best of my knowledge) require a physical attachment to a computer in order to load on the jailbroken firmware.

That all being said, I will be one of the first to say that jailbreaking a device does not make it unsecure. It becomes unsecure when you jailbreak and install potentially harmful apps only available with a jailbreak or apps which create extra security holes. However, there is the concern that if a jailbreak can be installed via an iPhone browser, a modified firmware with security holes and viruses could be installed to. Again, though, I wouldn't concern myself over it as long as you're running a semi-new iOS firmware.


SSH keys - passwords policy - can passphrase be the same as password?

First, you should look into the ssh-agent and the ssh option -A (ForwardAgent).

This might simplify your life a bit because it allows you to have the keys unlocked at the terminal where you are working, but use them at remote locations.

Secondly, I would recommend that your key-password not be the same as your login password. Having the key-password the same as your login password means that an attacker (or bad actor) who gets your login password gets access to all your machines.

Having different login passwords for each machine is probably a good idea.

Having a different key for each machine is probably not that useful for you. Having a single key that authorizes all your machines is probably your best bet for an initial configuration.

Open-SSH now has support certificates if you want finer-grained control, however, that is more complicated to set up, so I would recommend you start with the simple configuration initially.


Do keyfiles actually add any meaningful security in the presence of strong passwords?

Yes, keyfiles add some security. That added security may or may not be useful depending on the circumstances, but it's there.

A (properly randomly generated) keyfile has at least 128 bits of entropy. That's a lot more than a decently memorable password. With proper hashing, a long enough but still memorable password cannot be cracked in a reasonable time at a reasonable cost. However a keyfile is more future-proof than a memorable password.

More importantly, combining a password with a keyfile means that you have two authentication factors. (That's assuming you type the password rather than storing it in a file on the same machine, otherwise the password and the keyfile play the same role.) A password is “something you know”, whereas a keyfile is “something you have” — you have the storage media containing the password.

Multi-factor authentication is useful because different factors are subject to different threats. Malware running on the machine where you use the credentials is the worst case scenario: it can snoop on any credential you enter in any way whatsoever — and it can impersonate or subvert the application anyway, so you've lost regardless of what happens to your credentials. Many other attacks only affect one vector. For example, an attacker who steals backup tapes can obtain the keyfile but not the password. Conversely, there are many attacks that can reveal a password but not a keyfile, such as an shoulder surfing (possibly helped by a camera), or a hardware keylogger, or any other form of physical snooping (e.g. through sound or radio emissions).


Update: This answer is currently outdated. After having its servers raided by the FBI, TorMail no longer exists. I currently use CounterMail.

TorMail is the best* mailing service for anonymity. Why?

Absolutely no signup confirmation required (unlike GMail for example).
Accessed via the Tor network (Even the mail server doesn't know your IP).
Unlike other mailing services (Hotmail, GMail, Guerilla Mail, even Hushmail), TorMail doesn't have any info about you** to give to authorities even if forced by a court order.

*Some time ago I was very interested in this subject, I've looked into it a lot, and when I say "best" I mean among the ones I've looked into.

**They might have some information about you, like the signature provided by your browser, but not your IP. But they claim they don't keep any logs, and personally I trust them to some extent.


What are the TCP header features that are included in DoS buffer overflow?

It varies according to the service and the attack. DoS attacks tend to fall into three categories; saturating the network connection (a.k.a. bandwidth flooding), overloading the service (a.k.a. application flooding), or overloading the firewall (a.k.a. firewall flooding).

Network saturation works by sending so much data to the server that it uses up all of the bandwidth, resulting in most genuine users (and most of the attacker's traffic) being unable to reach the server. This can be done in many ways; typically by sending large amounts of UDP or TCP control packets to the server. This will make it difficult for genuine users to reach any service on the network that the server is on, and make it difficult for data to get out of any server on that network back to the Internet. Such traffic can be relatively easily detected and blocked upstream, but as the source IP addresses are almost certainly spoofed, it's difficult to track down. The attackers don't need to actually create any network connections, so the traffic doesn't have to have real IP addresses. In a variant of the attack, the attackers spoof the server's IP address to send TCP SYN packets to non-existent services on thousand of servers on the Internet, who then send TCP RST packets back to the server.

Service overloading works by attacking the service specifically, using up resources on the service. This can be done in a variety of ways, but usually it's done by making lots of requests in a very short period of time, using up all of the resources on the server. This might be random logins or anything else that the service is vulnerable to. (Note that other attacks, e.g. brute force hacking of administrative accounts, may produce the same result.) This relies on real network connections, so the source IP addresses are real, but the machines are probably part of a botnet.

Firewall overloading works by opening lots of TCP connections, but not necessarily sending much in the way of data. Firewalls have to handle network connections between networks, and some come with security scanning functions. For the latter to work, they have to monitor the connections. This means that they have to keep details of the connection, and with limited resources, it is possible to use up all of the connections available by opening too many network connections; hence preventing the firewall from accepting any new connections until some of the existing ones time out due to lack of traffic.


Dilbert's Pointy-Haired Boss & Influencing executive perspectives on Information Security

When it comes to business management, it always comes down to ROI. If you are not hitting them at that level, then you will likely lose.

So, when you talk about the "true nature" of the risk, what are you talking about, if not the ROI? It is your job to know the right answers and the best practices, but it is management's job to weigh all the factors, including impacts. Talk to them on that level, without being a 'chicken little'. Simply communicate.

So, keep doing what you are doing. Relate the risks to the impacts that management cares about. Then, if you have done your job and told them what they need to know,  let management do their job and make the decisions about what to do about it.


CVE is not going to provide that level of information, as you probably saw. CVSS, on the other hand, does. CVE often links to the NVD, which uses CVSS scoring, so it might be an easy mistake to make.

Many information security people confuse "risk" with "impact". So, if we assume that they meant "impact and probability are based on CVSS", then everything makes sense.

Here's an example:
https://nvd.nist.gov/vuln/detail/CVE-2017-14888

Impact
CVSS v3.0 Severity and Metrics:
Base Score: 7.8 HIGH
Vector: AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (V3 legend)
Impact Score: 5.9
Exploitability Score: 1.8

Attack Vector (AV): Local
Attack Complexity (AC): Low
Privileges Required (PR): Low
User Interaction (UI): None
Scope (S): Unchanged
Confidentiality (C): High
Integrity (I): High
Availability (A): High

The long string of codes helps to define the problem.

Impact and probability are often determined directly from the "Impact Score" and "Exploitability Score" of the vulnerability. Whether they should do that is another issue entirely. But it is a common practice and a straightforward thing to do for consistency in a research paper.


Browser hijacked - how to fix and prevent?

1. What are the security risks of this hijack?

If it is a simple browser redirect the risks maybe limited. Their business model may simply be to infect widely and make money from directing you to advertising sites. Not to unnecessarily alarm you but the danger is that the standard modus operandi these days is to compromise a machine and then download a cocktail of malware (Trojans, key-loggers etc) as well as using the machine in a bot-net

2. How do I remove it completely?

Only way to be absolutely sure is to do a complete format your drive and restore from backup (use the OS re-install media to format the drive). Update all patches and install updated AV from another computer prior to re-connecting to the Internet. Still may not save you if there is a hidden  root-kit that is making a part of the drive unwritable which may need a new hard drive or BIOS update at worst case. As @Rory-Alsop said contact the AV vendors for your particular strain to determine optimal removal procedures. I have found Hijack this particularly good in the past (http://free.antivirus.com/hijackthis/). It is not an automated program but lets you manually go through and examine things like browser hooks which is usually how redirect type malware works.

3. How does it get on my computer? (drive-by download,embedded in email attachment, etc)

No way to know for sure. Could have been a website even a legitimate one, email as you say, even infected USB drive.

4. How can I prevent it from happening again?

Take care. Key steps:

Use and keep an Anti-virus uptodate. Free ones are Clam AV, Microsoft security essentials
Patch everything regularly - use software that has auto update
Minimize software with big attack surfaces like Adobe Flash, Acrobat, MS Office, Java. There are good open source alternatives like Open Office, PDF Creator. Millions of people have iOS devices without Flash - you don't need it.
Use simple browser extensions like HTTPS Everywhere and No Script
Install and maintain a personal firewall. Windows has one and so do most AV packages
Do not use vendor-supplied or simple passwords. Use a password manager. Consider changing at least your important passwords
Most importantly: practice good Internet hygiene; not clicking on any links from
senders you do not recognize, not opening email from senders you do not recognize. Avoid sites that maybe bad for your computers health and your marriage!


How does one make password easily forgettable?

We tend to remember passwords automatically and (I think for many people) using auditive memory, which makes them prone to blurting them out under duress. There has been research on other forms of passwords, such as the broad class of graphical passwords, for which a classical article is The Design and Analysis of Graphical Passwords by Jermyn, Mayer, Monrose, Reiter and Rubin at Usenix 1999.

Suo, Zhu and Owen's 2005 survey covers some developments in graphical passwords. Their survey tends to show that a graphical password scheme with sufficient entropy would require a large amount of small steps, and with most techniques presented each step is prone to being revealed under coercion.

A well-known implementation of graphical passwords is the connect-the-dot scheme used on Android phones. This particular implementation does not have much entropy and is not good against hardware attacks (such as smudge observation) anyway.

I am also reminded of an old (2000) message on the Caml mailing list about Rubberhose, an early filesystem with deniable encryption, in which Julian Assange (now better known for other works) explains how his group has been thinking of using other methods for keying such as gestures (maze walking) and simile problems. I haven't found any later publication elaborating on these musings.

A 2009 recent study by Chong and Marsden shows that gesture-based passwords, at least with the constraint of recording them on a mobile phone, are less easy to memorize than PINs. I don't know how they would fare under the different point of view that passwords may be harder to memorize if that makes them easier to forget or avoid revealing.


This isn't the type of thing that is easy to remotely troubleshoot, you should speak to your training provider for technical support.

Besides other users on the network, is there a reason why you cannot use a bind shell. While there are good reasons to choose reverse over a bind shell for production infrastructure a  bind shell mitigates a lot of potential networking problems


How to fingerprint a server with Netcat?

It is not enough to open a connection to the target on port 80. You also need to perform an HTTP request like

GET / HTTP/1.1

and ideally send a user-agent...


Check sources for the WPS handshake attacks from the WIFITE package.

I remember it listing clients of all scanned APs, with MACs.

(Needs clients info to force deauth and capture handshake)

https://github.com/derv82/wifite/blob/master/wifite.py

class Client:
    """
        Holds data for a Client (device connected to Access Point/Router)
    """

    def __init__(self, bssid, station, power):
        self.bssid = bssid
        self.station = station
        self.power = power

Also

https://gist.github.com/garyconstable/1dca3c32dfd05f0bd15f

#sniff for client mac's
    de.sniffClients()

I don't know python very well, but it's in there.

Comment: remove inaccurate pieces of code via edit


Is storing passwords encrypted with GnuPGP on an anonymous FTP server safe?

Risks of Exposing Encrypted Information

  With it being encrypted I assume having it publicly accessed wouldn't affect security as the encryption setup would make it pointless for anyone to try and decrypt it.

Your encrypted information will stay private as long as

the crypto works (no flaws in the underlying mathematical principles are found),
the crypto software (GnuPG) works (no bugs in the implementation of the cryptographic algorithms) and
you don't perform any mistakes (for example uploading the unencrypted version by accident, or revealing the passphrase/key otherwise).

Be aware that an attacker archiving the files might be able to decrypt it well in the future if any of those incidents trigger!

In case of exchanging messages through some unsafe channel, you might (have) to accept this risks. I wouldn't accept them by publishing encrypted files if I could mitigate through additional access restrictions.

  Is there any way that anyone could gain access to the passwords stored in the text file without the permissions I have set in GnuPG? Is there anyway data could be leaked in my setup that would give it to someone without the private key?

To wrap up on this: while cryptography is safe in principle (and at least no known vulnerabilities exist), things might change in future. Not publishing contents will keep this safe. Accidental disclosure of encrypted content is probably the biggest risk (and everybody including "the best" might make a mistake at some time), while access restrictions would at least add another safety net.

Metadata

  Is there anyway data could be leaked in my setup that would give it to someone without the private key?

There is another point to this question: be aware that several metadata is publicly shared, which might be critical or might not be. When you change the files, their size, and if you also store it, even the name. You could mitigate some of those (for example, overprovision file size to hide size changes and not store the file name); but you especially cannot really hide file changes (even if you store faked time stamps, an attacker could simply fetch it in intervals and check for changes), the only option I see is providing "faked" changes every now and then.


Can GET Requests with Spring Rest controllers be intercepted by attackers?

As long as you use TLS in the websocket, the requests between the server and the clients are going to be encrypted, so you don't need to encrypt again the messages.
Encrypting them with AES on server-side to provide encryption at rest should be more than enough.

If you don't use TLS, then yes, the attackers could sniff the traffic and extract the content, but sending the key along with the encrypted message is not solving anything, since you also provide the attacker the way to see the original message.

Also, another drawback to send the decryption key to the frontend, is that you are sending the key to a client that you do not control, which can cause more problems:

You send the decryption key to an endpoint that you do not control
If there is only one key in the server for all the conversations, you are giving the key of decryption to a possible attacker that could compromise the message database.


In What Ways Can X-Foward-For Header Information Be Used In An Attack

With enough traffic from your internal users, an attacker could map the internal networks of an organization. There might be very low value in this data, however, if DHCP expires IPs quickly, or if the internal network is predictable (or uninteresting) on its own. It would also require a lot of traffic from the network's users to be helpful.


How difficult is it to brute-force Windows EFS encryption?

It depends on how EFS is set up, and what version of NTFS you're using. For the purposes of this question, I'm going to presume a modern version of NTFS (i.e. >=3.0) on a modern operating system like Windows 8.1 or 10.

In a single-user environment outside of a domain, by default, files are encrypted in a 3-stage process. First, a random File Encryption Key (FEK) is generated and used to encrypt the file with 3DES or DESX. This key is then encrypted using a user-specific asymmetric key pair, and this encrypted key is stored in the file's metadata. The asymmetric key pair is stored on-disk in an encrypted form, using a key known as the DPAPI Master Key.

The DPAPI Master Key is derived from a combination of the user's NTLM password and their SID (unique identifier for the user). When I say the NTLM password, I mean their logon password, not the NTLM hash of their password. The EFS master key is derived using the Password Based Key Derivation Function (PBKDF2), which is sometimes referred to as "RFC 2898 derivation" in the documentation. This master key is not only used to store the EFS asymmetric key pair, but also any at-rest data protected by DPAPI.

Since the DPAPI key is derived from the user's NTLM password, cracking the NTLM hash gives you the information you need to derive the DPAPI key, which would allow you to decrypt the EFS asymmetric key pair, which in turn allows you to decrypt the $EFS streams which hold the FEKs, which in turn again allow you to decrypt file data. There are off-the-shelf tools for doing this in a forensic capacity.

However, there are other environments and configurations for EFS. For example, in a domain environment, it is possible to have EFS-protected files accessible from multiple users using domain-backed encryption certificates. In fact, even in single-user accessible EFS files, the EFS asymmetric pair can be domain-backed, allowing for EFS encrypted files to be accessed from any terminal regardless of where the file was initially encrypted. It is also possible to place either the DPAPI master key or the the EFS asymmetric key pair for a user onto a smart card, thus bypassing the need for storage of them on disk at all. These configurations complicate the situation beyond the simple case of "crack NTLM and you get the EFS files".

Additionally, if you use BitLocker disk encryption, your DPAPI master keys can be encrypted using the BitLocker keys too, allowing them to be secured with a device such as a TPM, which can have additional authentication requirements (e.g. smart cards) before the keys are unlocked.

It should also be noted that, upon login, the system stores a cached copy of the DPAPI master key in memory in order to access certain encrypted memory segments and, of course, the EFS asymmetric key pair. If you're on a running system with administrative privileges, you can use a number of tools to dump the EFS keys, DPAPI master key, and LSA protected areas. This obviates having to crack the NTLM password at all.