Should a pentest report include the tester's opinion?

In general, the three most valuable layers of penetration test reporting are:

Technical - What the problem is, how to repeat it, and how to fix: this is what the IT/Dev team will require and should be in technical language
Business - What does each vulnerability mean to the organisation in terms of business risk, impact, loss etc. - this needs to be in language a risk officer, FD or CIO can understand
Experience - This is the bigger picture based on experience with the client, in the industry, and in looking at long term trends and new threats. This should be aimed at the board and should provide strategic guidance

Opinion is usually too strong a word, as it can mean something quite strong, especially in an audit setting, which may mean you take on a high liability!

In your specific example, without further context, I would say the wording seems reasonable, and can help to raise the profile of an area they may have overlooked, and at least get on the radar from a risk perspective (what they then do with it is a business decision)


Why isn't the record of a TLS data application exchange signed by the server?

... if some server sent me illegal content that I did not ask for, they could incriminate me for having that content later and I do not have any proof that it was they that send me this content.

You can neither proof that somebody has send you some content nor can someone proof that someone has not sent you this content. Also, if someone sends you incriminating content they most likely don't want you to be able to proof this anyway and thus would not use a transport method which lets you proof this.

  I would not expect the server to sign every application data exchanged ...  but why not signing a hash (or a HMAC with the session key) with the private key of the server at the end of the communication? If both parties sign it, then as I see it, they both obtain benefits.

This was simply not a design goal of TLS. TLS is designed to protect against sniffing or modifying by some man in the middle, not that some party can prove that the other has sent something. In other words: TLS is not a secure everything you want protocol but has a specific goal - which is not the goal you expect from it.

Additionally, in order to let both parties sign their sent data both parties need to have a certificate. While certificates for server are the most common case (but it can be done without, like with PSK) certificates for the client are uncommon.

Also, if the signature is only added at the end of the connection as you propose the peer might deliberately or accidentally close the connection before the signature was sent. It is common though that the data gets already processed while more data still get received - which make it possible to incriminate you but make it impossible for you to proof it.

  but why not signing a hash ... with the private key of the server at the end of the communication?

The purpose of certificates inside TLS is for authentication (and maybe key exchange - but this is deprecated and removed in TLS 1.3). Authentication needs to be secure at the moment it is done and thus the certificate needs to be sufficiently secure for the moment.

Signing instead should provide proof long after the data where transmitted. This means that the certificate might need to be stronger (depending how long the proof should be fine) and that the private key of the certificate needs to be protected for as long the proof should be fine. If the private key is not guaranteed to be protected that long somebody else might create faked signed messages or might successfully claim that what you present is faked.


Is is possible to avoid internal seeding of a RNG and seed the generator manually using OpenSSL's RAND_bytes()?

Come to think of it, you could implement an engine with a weak RNG and insert it into OpenSSL using:

ENGINE_set_default(e, ENGINE_METHOD_RAND);

That should make sure that the random number generator is used. Of course it may be a good idea to ignore any seed information given to the random RNG by the OpenSSL.

This has the obvious disadvantage that it may be hard to find out when the random number generator is used for which function though. But I don't see how this couldn't work otherwise.


Confusion regarding PCI compliance in an office

Do people come into your office and pay you using credit cards?  If so, that's why it's falling on you:

  PCI DSS applies to all entities involved in payment card
  processing—including merchants, processors, financial institutions,
  and service providers, as well as all other entities that store,
  process, or transmit cardholder data and/or sensitive authentication
  data.

The question then is not "why is this falling on you" but "why is this falling on you now?"  Most likely they've been scanning your IP address space all along, and when  you spun up your "new modem supplied by Comcast" it lit up your scan results with discouraged TLS versions and weak encryption ciphers.  And those things need to be addressed for DSS compliance.


Is there a way to isolate every device on my network?

That's what a firewall is for. In your case a packet filter based solution (linux with iptables or similar) is probably mostly enough but if you want to have a more granular access (i.e. only specific pages of the internal web server) you would need application level control which a packet filter does not offer. The usual home routers are mostly not suitable for this purpose because the firewall they often implement is only for separating the internal from the external network, but not for separation between internal devices.


What can a lfi without ssh open be used for

You could poison log files for example if this is a LFI (which includes a file, i.e. executes any php code) to achieve RCE.
You could perform an HTTP request to the server using PHP code as the user agent, and try to load the log file using your LFI. If a require/include function call is made, the php code should be executed.
You will find additionnal information here: https://www.rcesecurity.com/2017/08/from-lfi-to-rce-via-php-sessions/ (and on multiple other pages on the internet :))
If all you can do is displaying files (i.e. a php file is displayed instead of being executed) then some people don't call this LFI but directory traversal or other terms (arbitrary file retrieval, etc.)


Protecting against spoofed email in alias/phrase field

DMARC (and SPF and DKIM, though those aren't strong enough to block with without DMARC) key solely on the domain in the address, not the free-form field known as Friendly From or Display Name (or Alias or Phrase). There is no such equivalent for Friendly From spoofing. (BIMI is an attempt at corporate logos, but that's again not Friendly From.)
For mailboxes you control, you can write a filter that kills these. I don't know GMail's options (start by enabling Gmail's advanced anti-phishing and malware settings), but using the F/OSS SpamAssassin software, you can write a rule like this:
header    MF_SPOOFED_SPOOFED_COM  From:name =~ /\@spoofed\.com\b/i
describe  MF_SPOOFED_SPOOFED_COM  https://security.stackexchange.com/a/237604/42391
score     MF_SPOOFED_SPOOFED_COM  10

I'm using the prefix MF_ because your Stack Exchange handle implies those are your initials. It's always good to take credit so you and your peers can troubleshoot what's going on when there's an issue.
For mailboxes you do not control, there's unfortunately nothing you can do to stop forgeries of your domain that do not use your exact domain in the From header address.


How Dirbuster find the files within a directory? (Differentiating between files and directories)

This question has been asked a few times- here and here- within the general SO community. From what I can gather, the synopsis is that you cannot tell the difference between a file and a directory, at least without some fu, and even then there is no guarantee.

This answer provided the most promise, and in summary states that you should just check for the presence of a file extension. And though this does not guarantee that a file extension will be present, it likely covers many use cases.


Who in UK I can report to if I know company is storing my password in plain text?

The Information Commissioner's Office is the relevant public body. You can report a concern online.

However, there is no explicit requirement to hash passwords. The Data Protection Act includes eight data protection principles; number is 7:

  Appropriate technical and organisational measures shall be taken against unauthorised or unlawful processing of personal data and against accidental loss or destruction of, or damage to, personal data.

Whether password hashing is an "appropriate technical measure" is open to debate - an organisation can argue they have other controls. I expect the ICO would only take action if there was an actual breach.


Can I rely on Operating System (OS) Anti Virus (AV) scanning to scan files shares?

It depends on the context.

You should consider some things like the following:

what type of files reside there and what can open/execute them
what OS(es) will open the target files
what capabilities your AV has

Explanation: If your files are generated and stored by a similar OS to the one you scan the location with, then it's pretty safe to do so. If the files are from a different OS then your solution is insufficient and will be as good as the AV solution is, which in turn can or cannot correctly detect dangers designed for other OSes than the host one and may or may not have advanced features (like centralized threat detection).


Authentication to SSH

Authentication takes two primary forms, username and password, and key-based authentication.

There is also an authenticity check performed when the client connects to the SSH daemon by confirming that the trusted public key has not changed by comparing the fingerprint that is in the trusted database known_hosts, and what the server presents. If these match, connection continues, the server challenges for authentication, and once validated, the full session is established.

What is mutual authentication?

Before talking about SSH, let's talk about mutual authentication in a typical implementation. A TLS mutual authentication presents certificates to both the server and the client, confirming identity. This is commonly used in B2B applications, such as API endpoints. This provides the benefits of PKI (encryption in transit, integrity checking, and revocation through CRL and OCSP responders) while providing authentication of the identity.

What about implementing that in SSH?

By default, this won't work. The SSH client connects to an SSH daemon. This would require that the server have client credentials on the client. Confusing? Let's take a step back.

User (You) -> SSH key -> Server

This is normal behavior. We want to flip that and establish trust in the reverse:

Server -> Different SSH key -> User (You)

This is dangerous. There are a few reasons why:

Compromise of the server would allow pivoting to the corporate desktop network, or to a user's home network. Either situation would be devastating.
ACLs in the enterprise should not allow this to happen. This makes pivoting and data exfiltration much simpler for an attacker.

Conclusion

This is possible, but rarely done, and is dangerous.


Can a lock picker slowly undermine the security of a deadbolt door?

The answer to your question is yes, though whether this will ever actually help them is dependent on the lock and their 'skill'.

With a typical (cylinder?) deadbolt repeated attempts can advance an impressioning attack with a key blank (see tylerl's answer for more detail), if using picking tools the extra visits will improve the feel for the lock and in theory will make the time to pick it quicker, though it should be noted that someone proficient at picking locks is unlikely to need multiple attempts against a simple deadbolt lock.

Lever tumbler locks, as used in some mortise locks, are more time consuming to pick, so fitting one of these (at least 5 levers is generally accepted as necessary) might be a good option. Multiple attempts against this type of lock is likely necessary to develop a successful attack against it so it will give you more opportunities to catch someone.

Restricting access to the lock so that it is more difficult to use lock-picking tools may be effective depending on the lock and installation, generally speaking a key needs less space to operate than lock-picking tools.

But if someone is determined it does not matter what lock you fit, with time and patience any lock can be defeated (eventually)...

Depending on the building layout the door could be bolted from the inside out of hours, so that the only entrances available to the attacker are ones that are covered by the existing camera installation.

It a mortise lock does not discourage them and you cannot bolt from the inside, the refusal to install an additional camera is an implied acceptance of the risk by the building manager - provided that person is authorised to accept the risk there is little more that can be done.

And to add, since this is an information security site, the computers that are behind this potentially insecure door, which is subject to a an observed threat should:

Have strong passwords configured (including BIOS) and never be left logged in;
Disable USB interfaces etc to prevent introduction of malware;
Be configured with full disk encryption so that if the attacker gets in and steals any machines they are of hardware value only;
Store all your backups and removable media somewhere else;
Conduct daily checks to make sure unauthorised hardware has not been installed (packet sniffers, key loggers etc).


MITM my own SSL connections with e.g. wireshark - no proxy

Wireshark alone does not do that, it can only watch the traffic if you already have knowledge of the keys/certificates in order for it to decrypt the traffic in the TLS connection. There is a type of proxy, a transparent proxy, that applications have to use because they sit on port 80/443 of the gateway and simply intercept all traffic.  This would be the approach you need if you want to be privy to the traffic involved in your mystery application.

If you wanted to stick with Wireshark, you could use a simple transparent proxy (with something like Squid) to hand it your own certificate and then watch the traffic and let wireshark decrypt it.  There are tutorials but it is slightly complex.

What you want is encompassed by a single product called Burp Suite, it will let you intercept the traffic (acting as a transparent proxy which the application cannot ignore) inject your own certificate, watch the resulting conversations, etc.

See the product page for more info: https://portswigger.net/burp/


Run native code from shell on read-only filesystem

Find a program with a vulnerability in handling command-line or environment arguments (nothing so far)

This is probably the most promising avenue.

In my case, I've been finally able to find a buffer overflow in the handling of an undocumented parameter of a custom proprietary utility.


What are the most common security threats that have to be considered when dealing with RDP?

Answering your edit part:

As the machine is a virtual machine it makes no difference (assuming the VM host is correctly patched and managed). The link in which you found covers the main answers to your question.


Does X.509 standard claim to check client certificate's expiration date on server side?

I don't think there is a specific standard dealing with client certificates. There is a general mechanism for certificate validation (RFC 5280) and the whole system of CRL assumes that certificates have a limited lifetime, because the CRL is only used for certificates which are not yet expired.

But note that the whole process of validating the trust chain and lifetime is only relevant if validation is done based on a PKI. If the server simply trusts a specific certificate or public key and the client sends exactly this certificate than the server might ignore any additional validations.


Do the Greenbone scan reports actually differ from a typical OpenVAS scan report?

I just got an answer to this question from a salesperson working at Greenbone. The OpenVAS-reports and the Greenbone-reports have indeed the same structure. So if you are using a parser which works on OpenVAS-reports, it will also work on the reports generated by the Greenbone appliance. The only differences are - as the salesperson put it - in quality. But this is something you should evaluate yourself, as I am in no position to justify this claim.


How to pentest Flash file on webapp with alowscriptaccess=samedomain?

Original source -- http://my.safaribooksonline.com/book/networking/security/9780596806309/inside-out-attacks-the-attacker-is-the-insider/content_ownership

2.4.1. Abusing Flash’s crossdomain.xml

The same origin policy can often be deemed too restrictive, causing application developers to clamor for the ability for two different domains to work interactively with each other. One of the first popular browser plug-ins to support such cross-domain interaction was Adobe’s Flash. Adobe understood the dangers of allowing arbitrary cross-domain access and implemented a security measure to determine whether Flash would allow for cross-domain interaction. This security measure is implemented via the cross-domain policy file.

Flash’s cross-domain policy file defines the “rules” for cross-domain interaction. The cross-domain policy file is simply an XML file named crossdomain.xml. Here is an example of a crossdomain.xml file:

<?xml version="1.0" encoding="UTF-8" ?>

<cross-domain-policy
    xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
    xsi:noNamespaceSchemaLocation=
    "http://www.adobe.com/xml/schemas/PolicyFile.xsd">

    <allow-access-from domain="*" /> </cross-domain-policy>

This crossdomain.xml policy file must be hosted on the server that wishes to allow for cross-domain interaction. Before allowing cross-domain interaction, Flash will check for the presence of a cross-domain policy file on the target domain. If no policy file exists, Flash defaults to the restrictive same origin policy and disallows cross-domain interaction. If a crossdomain.xml file exists on the target domain, Flash reads the “rules” contained within the policy file and allows cross-domain interaction based on the established rules. Once again, the entire premise is based on the fact that the cross-domain policy file must be served from the domain that wishes to allow the cross-domain interaction. By default, Flash will check for the presence of a cross-domain policy file named crossdomain.xml in the web application’s web root (http://www.example.com/crossdomain.xml).

Beginning with Flash 7, you can make Flash check for crossdomain.xml in arbitrary locations (not just the root of the web root) when the Flash component invokes loadPolicyFile() with a URL as the parameter (containing the location of crossdomain.xml on the target server).

NOTE

You can find more information on System.Security.loadPolicyFile() at the following website:

http://livedocs.adobe.com/flash/mx2004/main_7_2/wwhelp/wwhimpl/common/html/wwhelp.htm?context=Flash_MX_2004&file=00001098.html

The concept of Flash’s cross-domain policy is based on a few simple premises. A simplified version of the logic is as follows:

The cross-domain policy file must be located in a web-accessible path of the web server to allow for cross-domain access from Flash to that server.

The only way someone can put an arbitrary file into a web-accessible path of the web server is if he has administrative access to the web server.

Therefore, if the web server has a cross-domain policy file in a web-accessible path on the web server, an administrator must have placed it there.

This logic is inherently flawed because many web applications allow users to upload content to the web server. If the application subsequently serves that content under its domain name, that web application has unknowingly put itself at risk because of Flash’s cross-domain abilities. If an attacker is able to upload a crossdomain.xml policy file, the attacker can use an evil Flash applet on her web server to attack the vulnerable application. This evil Flash applet will be able to make cross-domain requests to the vulnerable web application and those requests will be made with the session cookies of any unfortunate users who happen to stumble upon the attacker’s website. To make matters worse, the cross-domain policy file need not have the .xml extension. Flash’s security criteria will honor any file extension.

NOTE

Adobe Flash 9.0.115.0 allows for the specification of “meta-policies.” These policies define which policy files on the server should be honored. You can find more information on meta-policies at http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security_03.html.


Increasing the Calculation Cost of Hashing

No, it is not a "secure" way. It is a home-made construction that merely throws together hash functions and symmetric encryption under the hope that the resulting mixture will be strong in some way.

Truth is, in the specific case of password hashing (as opposed to simple hashing, which is a very different activity), such slapping of algorithms together tends to work. But you still managed to get several things wrong. Namely:

Your system is not salted, so when an attacker must crack several passwords, he can optimize things with parallelism and precomputed tables.
The point of using many iteration is to make each password try expensive, but the attacker has the resource to use dedicated hardware that will be more efficient than yours. In this case, both MD5 and AES can be considerably sped up on off-the-shelf GPU (for AES, using bitslicing techniques, as in the Käsper-Schwabe implementation), thus allowing the attacker to hash more passwords per dollar than you.

Read this answer for more information on what is needed for good password hashing. The short summary is: use bcrypt, with one of the already available libraries. It will be stronger than your creations, and easier to implement since it is already done.


Is full disk encryption on a server in a secure data center pointless?

Two generic things you apparently have missed:

In case of disk failure, having the data encrypted at rest solves the issue of having potentially sensitive data on a media you can't access any more. It makes disposing of faulty drives easier and cheaper (and it's one less problem)
Full disk encryption also makes it harder for an attacker to retrieve data from the "empty" space on the drives (which often contains trace of previously valid data)

And if you're using VMs:

Encrypting the partition makes you less dependent on the security of your hypervisor: if somehow the raw content of one of your drive "leaks" to another VM (which could happen if the drive space is reallocated to another VM and not zeroed out), that VM will be less likely to have access to the actual data (it would need to obtain the decryption key as well).


Has any exploit leveraged a Video Driver flaw in WebGL?

Absolutely. Quite a few, in fact. A quick web search turned some up in just a few minutes. These are the CVEs with a link to further information from NIST, the description, and the CVSS score. They are all related to WebGL handling in various popular browsers. Note that these are all vulnerabilities, not exploits, as there is a significant difference. A vulnerability is a security bug, whereas an exploit is anything that actually takes advantage of said security bug. While I haven't looked for an actual exploit for these CVEs, the fact that there were vulnerabilities means an exploit is absolutely possible.

CVE-2017-5112 (8.8 base score)

  Heap buffer overflow in WebGL in Google Chrome prior to 61.0.3163.79 for Windows allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page.

CVSSv3: AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

CVE-2016-2824 (8.8 base score)

  The TSymbolTableLevel class in ANGLE, as used in Mozilla Firefox before 47.0 and Firefox ESR 45.x before 45.2 on Windows, allows remote attackers to cause a denial of service (out-of-bounds write and application crash) or possibly have unspecified other impact by triggering use of a WebGL shader that writes to an array.

CVSSv3: AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

CVE-2014-1502 (6.8 base score)

  The (1) WebGL.compressedTexImage2D and (2) WebGL.compressedTexSubImage2D functions in Mozilla Firefox before 28.0 and SeaMonkey before 2.25 allow remote attackers to bypass the Same Origin Policy and render content in a different domain via unspecified vectors.

CVSSv2: AV:N/AC:M/Au:N/C:P/I:P/A:P

CVE-2013-1729 (2.6 base score)

  The WebGL implementation in Mozilla Firefox before 24.0, when NVIDIA graphics drivers are used on Mac OS X, allows remote attackers to obtain desktop-screenshot data by reading from a CANVAS element.

CVSSv2: AV:N/AC:H/Au:N/C:P/I:N/A:N

CVE-2012-3968 (10.0 base score)

  Use-after-free vulnerability in the WebGL implementation in Mozilla Firefox before 15.0, Firefox ESR 10.x before 10.0.7, Thunderbird before 15.0, Thunderbird ESR 10.x before 10.0.7, and SeaMonkey before 2.12 allows remote attackers to execute arbitrary code via vectors related to deletion of a fragment shader by its accessor.

CVSSv2: AV:N/AC:L/Au:N/C:C/I:C/A:C


Biometric versus other Two Factor Authentication Mechanisms

There's a few other reasons:

Error rate - false accepts and false rejects are still unacceptably high for many types of biometrics.
User acceptance - still not widely trusted by users - the various privacy concerns are still quite high, and the idea that a part of your body is now a security mechanism is somewhat freaky for some folks.

Security best practices these days (like the CISSP certification's baseline for security practices) don't point towards Biometrics being the end-all, be-all for security.  The best practice is to build a system with a collection of authentication mechanisms that are appropriate for the system, the information in it, the expected threats and vulnerabilities, and the ways that the system must be used.

I don't know that anyone could say beyond doubt what the "state of the nation" is - that's a pretty broad assertion.  But I can say that common best practices don't currently force biometrics as a one size fits all solution.  I'd say, at best, they are something that is still under development and treated with a certain amount of dubiousness.


Is there any way to secure old unpatched Linux server?

Put a firewall in logging mode in front of it.  Watch all the traffic coming in and out of it and run any reports or processes that this server should do so you make sure to capture all the types of communication the firewall rules have to allow.  Create rules to allow only this traffic to pass.  Once you are confident you have everything set correctly drop and log any traffic that is outside the normal traffic parameters.  Make sure to alert on anything logged so it can be investigated to be added as a rule or as an intrusion attempt.

Edit:  I've assumed based on the question wording that this is an internal server.  Also, use the opportunity when profiling the traffic to look for indicators of existing compromise.


Command Prompt Opens and Closes Immediately

This problem can be caused by two things.

The first is browser extensions. I you have installed any extension from any unknown source that may cause changing your home page and showing ads. All you need to do is to remove that extension. If that doesnt solve the problem you may need to uninstall the browser and delete the files in this folder (check all user accounts for this location):

C:\Documents and Settings\*UserName*\Local Settings\Application Data\Google\Chrome\User Data\Default\Extensions

Second, if you have malware, adware or whatever you need to find it. See how to find manually a virus malware adware or any infecting file.


Should the Secure cookie flag also be set on HTTPS only websites?

There is no need to set this attribute if the traffic between client and server(s) for the cookie domain will always be end-to-end encrypted. But, can you really be sure that it is?

Server misconfiguration might cause plain traffic.
While example.com might be fully encrypted, sub.example.com might maybe not, but the cookie might be valid for this domain too.
There are attacks like sslstrip which cause a plain connection between client and MITM attacker even if the connection between attacker and server is encrypted.

Thus, in the interest of robustness it is better to set the attribute even if it seems to be unnecessary. See also Knowing a web application is HTTPS only, do HTTP cookie need the secure flag?.


Are all fields of the PE certificate directory hashed during authenticode signing?

Nope. The entire certificate entry table is excluded from the Authenticode digest.

The intuition for this is that, in the case of multiple certificates, the length and other metadata in the certificate entry table would cause problems for consistent hashing.

MSDN offers similar reasoning (link):

  When included in a certificate, the image digest must exclude certain fields in the PE Image, such as the Checksum and Certificate Table entry in Optional Header Data Directories. This is because the act of adding a Certificate changes these fields and would cause a different hash value to be calculated.


AES is encryption; it is meant to maintain confidentiality. Encryption does not maintain integrity by itself: an attacker who can access encrypted data can modify the bytes, thereby impacting the cleartext data (though the encryption makes the task a bit harder for the attacker, it is not as infeasible as is often assumed).

To get integrity, you need a MAC, and HMAC is a nice MAC algorithm.

In many situations where encryption is mandated, integrity must also be maintained, so, as a general rule, AES "alone" is not sufficient. In your case, the potential attackers are the customers themselves; each customer may try to alter the URL so as to access the data of somebody else, or to be able to register under another name, or whatsnot. As I understand it, your "client" wants to remain the master of registration; he wants to decide which customer can register and under what name. Checked integrity is thus necessary.

There are several ways to combine AES-based encryption with HMAC; most of them are bad. See this question for some discussion on the subject. To make the story short:

If you can, use GCM or some other mode which does all the hard work of combining encryption and MAC safely.
If you cannot use GCM (for lack of support in your server-side programming framework), then you must do things old-style:

Hash the key K with SHA-256 so as to get 256 bits of "key material". Split that into two halves: 128 bits for encryption (Ke), 128 bits for MAC (Km).
Generate a random IV of 128 bits. You need a new one every time you encrypt, and you want to generate it with a strong PRNG (/dev/urandom).
Pad the data (usual PKCS#5 padding) so that its length is a multiple of the AES block size (16 bytes).
Encrypt the data with AES in CBC mode, using the IV generated just above, and Ke as key. Let's call C the resulting ciphertext.
Compute HMAC/SHA-256 with key Km over the concatenation of IV and C, in that order. Call M the resulting value. It is crucial that the IV is part of the input to HMAC.
Concatenate IV, C and M, in that order. This is your "registration key".
When receiving a registration request, first verify the HMAC (by recomputing it), then (and only then) proceed to the decryption step.

Of course, all of this assumes that there is a key K, that your client can use to generate the registration keys for the customers, and that your server also knows in order to verify and decrypt incoming registration requests. As with all keys, be careful where you store it.


What layer does dictionary attacks take place on?

Dictionary Attacks in Networking

Mostly the application layer if you are talking about the OSI model, one exception being SMTP on the OSI session layer. For TCP/IP it may just be the application layer for all intents/purposes today, though authentication does occur at the TCP/IP link layer in PPP. I can't give many examples here.

But anywhere you see password authentication in a network protocol, or outside of any network consideration, it might be vulnerable to dictionary attacks. OSI session layer has a few (e.g. SMTP). You also could think of any protocol with password-derived cryptography, but getting abstract now.

General Dictionary Attack Scenarios

I would say that dictionary attacks are best considered agnostic of layers as a concept. Instead,  to effectively pursue, impede, or prevent an attack, one should consider the act in terms of context. The two contexts are:

Password-based authentication using brute force. For example...

Spamming website login processes via HTTP POST appearing to come from a form.
Spamming the authentication of an OS login to a computer with no hardware TPM.

Decryption of ciphertext via brute force of passphrase used in key derivation.

The first can be impeded to the extent that it's practically impossible to crack (too many failures means your account gets locked, x unavailable for y minutes, all data gets wiped, and so on).

The second one is impossible to prevent, since unfettered access to ciphertext means the attacker could use the best rainbow table in the world with millions of dollars worth of specialized hardware to spam everything it can think of for as long as it needs, and meanwhile you are none the wiser. Though the key derivation function can impede by demanding more resources to compute.

In terms of layers in the OSI model or TCP/IP, all that above was to make you think of situations in which an attack may apply to no layer in particular, even as a stretch, as the attacks could actually be bare metal (physical, but doesn't pertain to networking). Other times, maybe it's just local to the machine and does not involve networking.


Aireplay handshakes, were working now has an error

Load the captured packets into Wireshark, and check if they are valid. If you find some .pcap file corrupted, you can safely delete it. If you already have a valid handshake, you don't need to capture again for testing against another dictionary list, for the same target.
Having a lot of handshakes won't help to speed up the cracking. You need only one valid handshake for each target (which is composed of a minimum of two packets), but you must be sure that the handshake is valid, otherwise you may waste your time. Take a look at this for more details.


Using GPG or PGP for symmetric database encryption/decryption in c#

The central part of PGP/GPG is the asymmetric cryptography. It does not make sense to use GPG without that part because the rest is just simple symmetric en-/decryption.

Using the cipher algorithms from GPG also does not make sense as Dot.Net has them already implemented. I am not sure if the GCM mode is also present but if not you can still use the Dot.Net version of BounyCastle, which has GCM support.

Since you don't have a database provider that supports encryption, in my opinion your only option is to develop your "own protocol".

How many keys to use and how to cipher what with which key depends on the security needs of the data you are storing. Make sure to discuss your final design intensively here on Stackoverflow or on the IT Security branch.

BTW: Even if GCM outputs a cipher text exactly as long as the plain text it requires further parameters like IV and authentication tag (auth tag is optional) which have to be saved. Therefore the data to be saved is again larger than the plain text. But as long as you don't have millions of records this doesn't make IMHO a big difference nowadays.


How to prevent network administrators from accessing USB drive

You effectively can't. If you're on somebody else's machine and they have administrative rights to it, then that's the game.

The quite fancy answer be mandatory access control systems like SELinux which hold a concept higher than root that would at least require a reboot and direct system access to change the settings.


If you could have only one book on web security, what would it be?

Many people do recommend this one book: The Web Application Hacker's Handbook: Discovering and Exploiting Security Flaws, which I also find very useful. But you should not rely upon only on one book. This book was released back in 2007 year, now there have appeared many new technologies. So, besides books you should follow standards, RFC's and other documents. I know other really good and fresh book. I have only hard copy in German, not aware if it is available in English - Sichere Webanwendugen.


How could criminals use stolen EMV credit cards in 2011?

One of the features of EMV is that a transaction can be approved offline by the chip, if neither the chip nor the terminal flags it to go online.   The terminal simply stores the chip's response, and sends it to the processor as part of end-of-day settlement.   Some terminals aren't even capable of online approval, although I don't know how common that is.

This is an advantage for the merchant, because they can process transactions faster and/or without having to dial into a processor to approve it online.  The only advantage to the cardholder is speed.  I presume the issuing banks have some advantage, but I'm not sure what it is.  If you assume that EMV cards cannot be copied, or used by someone else if stolen, it's just as safe as approving online.

All this is to say, if they were using the stolen cards for  amounts below the floor limit configured in the terminal, it is very possible that they were not authorized online, and thus not flagged as stolen at the time.  It's only at the end of the day that the merchant would discover that it was a fraudulent transaction.

In recent years, has connections to the processor have gotten better in Europe, more transactions are being processed online anyway. I know that Visa recently mandated that the floor limit for visa cards should be reduced to zero, forcing every visa transaction to be authorized online if possible.


Securing php files from external include

Your PHP files contain scripts that is run on the server side only.

A scenario in which someone could run your PHP scripts on your behalf means either your web application/server is compromised or you have given specific  permissions to a trusted third party for that to happen.


Permissions for .htaccess file that needs to be modified by sister application?

Yes, XX7 is very bad for security, it gives read, write and execute access to all users and should be avoided unless absolutely necessary. A malicious user could use the .htaccess file to get a malicious or sensitive file to become visible to the web interface. Then, using the web inteface user (who may have elevated privileges) the malicious actor could perform actions under that context.

If you can get the sister application and the .htaccess file to have the same owner/runner then 700 should work, otherwise try to get them into the same group and have 770.

Obviously the more users with write access to a file the less secure it is.

If some level of access ( > 0) is required for .htaccess, consider:

1 (execute)
4 (read)
5 (read and execute)


When do I use IPsec tunnel mode or transport mode?

From Cisco: http://www.ciscopress.com/articles/article.asp?p=25477

  Tunnel mode is most commonly used between gateways, or at an
  end-station to a gateway, the gateway acting as a proxy for the hosts
  behind it.

  Transport mode is used between end-stations or between an end-station
  and a gateway, if the gateway is being treated as a host—for example,
  an encrypted Telnet session from a workstation to a router, in which
  the router is the actual destination.

So what ARE the differences:

Tunnel mode protects any internal routing info by encrypting the IP header of the ENTIRE packet. The original packet is encapsulated by a another set of IP headers.

NAT traversal is supported with the tunnel mode.
Additional headers are added to the packet; so there is less payload MSS

Transport mode encrypts the payload and ESP trailer ONLY. IP header of the original packet is not encrypted.

Transport mode is implemented for client-to-site VPN scenarios.
NAT traversal IS NOT supported with the transport mode.
MSS is higher

Transport mode is usually with other tunneling protocols (GRE, L2TP) which is used to first encapsulate the IP data packet, then IPsec is used to protect the GRE/L2TP tunnel packets.

EDITED:

Here is a detailed read on the differences from Microsoft:
http://technet.microsoft.com/en-us/library/cc757712%28v=ws.10%29.aspx


I have just finished reading the post against bastion hosts. At first the author says that doing that goes against what the majority consideres as best practices. Attempting to make that interesting post short I would identify the following most important points:

nothing is wrong per se when using a bastion host it may simply be not as powerful as you could hope
the drawbacks are:

one more machine to maintain
a false security feeling could lead to lower the in depth protection rules - which is definitely bad.

IMHO this last point is the worst use case. People often want to just buy security without worrying of all the security rules, and are told that a bastion is their solution. What it is not. A bastion host is indeed a nice tool to increase security, but it will be helpless if the princip of least privilege is not respected.

Long story short, my opinion for best security practices is:

define what threats you want to considere
define what are the minimum rights that must be enabled to allow you business process
ensure that only that rules are allowed

Then if your security threat analysis shows that you need a strong protection at you internal network entrance (which is the common use case), then a bastion host is probably usefull, provided it is consistenly monitored and maintained with up to date versions of its software. If you cannot meet that condition, then you will only have a false security sentiment. If you find you saying My security relies on the bastion host, and I do not want to be bored with any other security consideration, then the bastion host is probably more harmfull than usefull.


Alice and Bob agree to give a message to Carol

You need to use signatures instead of encryption.

Eg. Alice signs a message with her private key and optionally encrypys it with Bobs key. Bob decrypts the message (if encrypted), signs it, opyionally encrypys it with Carols public key and sends it to Carol. Carol checks that the message is signed by both Alice and Bob.


Implications of hashing to UTF-8 in a cryptographic function

First, Base64 will use, well, 64 different chars (hence the name) to encode binary data. The almost only set of symbols used is this:

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/

I am not aware of any implementation that uses a different one.

According to Wikipedia, "A hash function is any function that can be used to map digital data of arbitrary size to digital data of fixed size." Basically, you use a hash function to turn an undetermined sized text into a fixed size number.

The data returned from the hashing function is binary, not text. It seems a text because is more useful (and easy) to encode the result in a text representation than to handle a binary one. So they generally (but not always) encode the result before displaying. Generally the hash function will return hexadecimal encoding, not base64.

On PHP, if you execute this:

$a = sha1('some string', true);

It will return the binary data, not the hexadecimal representation.

On Python, you can use sha.digest() to achieve the same: you will get the binary 20-byte representation, not the encoded value.

When you encode your binary data in base64 (or uuencode, or yEnc), you are not changing the data, only the representation. It's just like the relation between one trillion, two hundred and seventy four million, five hundred and two thousand, nine hundred and fifty tree and 1274502953. The encoding does not change the value.

Using UTF-8, UTF-32, Base64 or ASCII will not change anything.


What does setting Unrestricted = false on PrincipalPermission supposed to do?

It's not more subtle.

Setting Unrestricted = true means it will match any principal, and so setting the Authenticated and Role properties is pointless, because once the framework sees Unrestricted = true, it will always set Authenticated = true and Role = null and the demand will always succeed, regardless of the the principal.

So, it sounds to me like setting it to false (or simply removing it from the attribute altogether) is indeed likely what you want to do.


What if the Local Windows Cert Store is Compromised?

That does indeed severely compromise security. There are no ifs, ands, or buts about it: if you have CAs that your computer trusts but are not the real ones, anything that relies on the OS store won't work (I believe Firefox has its own certificate store, but then that has to stay secure). See: the Superfish debacle, where the problem was that a hardware manufacturer added a certificate into the Windows cert store and also included the private key on ad software shipped with the computer.

The reason this isn't such an issue in practice isn't that it's easy to mitigate; it's that it doesn't really let an attacker do anything they couldn't do anyway. Modifying the certificate store for a user requires access to that user's account or an administrative account. Modifying the certificate store systemwide requires access to an administrative account. On a machine where an attacker has this level of privilege, they can already access whatever your user account is doing. An attacker with an admin-level compromise can just install a keylogger and screen viewer.

Any security system has a threat model, which is the attack scenario it is designed to defend against. A compromised client is not part of the TLS threat model: the model only posits an attacker who can manipulate network traffic (including redirecting it to his own machines to serve up bad content). TLS is not intended to secure against a compromised machine on either end, nor is it capable of doing so.

In general, it is extremely difficult (or maybe theoretically impossible) to achieve security on a compromised machine. The correct approach is to prevent a compromise or detect and handle it, not to try to achieve security despite it.


If certificate authority generates key pair for us, do they maintain/have access to our private key?

This is a bad model. The proper way to request a certificate is to send a CSR (certificate signing request) to the certificate authority
The CSR contains your public key only (it is signed using your private key to prove that you own the private key, and to ensure integrity of the request contents).
You should not use a mechanism where the CA generates the private key for you, it is not needed and only adds more ways for your private key to leak.
Final note: as usual, context matters a lot: if the scenario involves certificate issuance within an organization (eg: internal CA for corporate infrastructure) it might be acceptable, especially if the organization has a good process in place for key management. If possible show the source of the slide, it might make more sense in context.


Convert RSA SSH public key file into x509 certificate

It is not possible to create a certificate out of the public key on the way you chose.

A certificate is a public key signed by an authority (normally a CA). So to create the certificate back from you public key you have to sign the public key from the same authority as before. Then you will get the certificate back.

To sign you need the private key of the authority. Also be aware that you new certificate willget another seriall number than before.


Automatic push on commit (on bitbucket repository)

If you can automatically push, all the secrets have to be on the server. So if someone breaks into that server he will be able to push to hat repository as well. From that point of view there is no difference in SSH passwordless key vs SSH key vs password. You will need to store it on the server that should do the push without interaction.


What happens if I change RR on my domain's DNS after DNSSEC has already been enabled?

What you suggest would be rather silly, wouldn't it? It would mean that you would have to disable DNSSEC every time you make any modification to your zone, which would both be very laborious and leave your zone unprotected for a long time (for the TTL on the parent zone).
When you enable DNSSEC, the parent zone adds DS records authorizing your DNSKEY to sign the records in your zone. When you change a RRset you simply sign it again with your key, resulting in a new RRSIG.
Furthermore, RRSIG records have Signature Validity Periods (RFC 6781, 4.4.2); you must resign the RRset before it expires. It's better automate this! Also, until the validity period expires, it would be possible to use the old RRSIG to sign an old RRset and perform a replay attack. It's all explained in detail in the RFC.


Which PFS Group is recommended for IPSec configuration?

What you refer to as "PFS Groups" are more precisely Diffie-Hellman groups. The Internet Key Exchange (IKE) protocol uses Diffie-Hellman to derive key material for both the IKE and IPsec security associations (SA). With IKEv2, the keys for the first IPsec (or Child) SA are derived from the IKE key material (there is no DH exchange during the IKE_AUTH exchange that follows the initial IKE_SA_INIT exchange).  A separate DH exchange may optionally be used with CREATE_CHILD_SA exchanges for Child SAs created later or their rekeyings. Only to rekey the IKE SA itself is a DH exchange mandatory (so even if no separate DH exchange is used for each Child SA, will their key material be derived from new DH secrets once the IKE SA has been rekeyed).

The currently defined DH groups for IKEv2 are listed in Transform Type 4 - Diffie-Hellman Group Transform IDs. In 2017, RFC 8247 was released with recommendations regarding algorithms for IKEv2, including Diffie-Hellman groups in section 2.4. According to it, the groups to avoid are

the MODP groups below 2048-bit (groups 1, 2 and 5), because even group 5 (1536-bit) is assumed to be breakable by nation-state-level attackers in the near future,
and those MODP groups with prime order subgroups (22, 23 and 24), as group 22 was already shown to be weak (breakable by academia).

So for MODP at least 2048 bit and for ECP at least 256 bit should be used. For a general assessment of the cryptographic strength of the groups keylength.com might be useful.

  What is the implication for using better PFS groups?

Two issues may arise:

The larger the group, the more computationally expensive the key derivation (this is mostly a concern with MODP groups), so as a gateway operator this might be a problem if there are lots of clients creating SAs concurrently (hardware acceleration can help).
Large MODP groups can potentially cause IP fragmentation because the IKE_SA_INIT messages, which transport the public DH values, exceed the MTU (in particular for clients that also send a lot of certificate request payloads). This is a problem if such fragments are dropped by intermediate firewalls/routers. IKEv2 fragmentation (RFC 7383) doesn't help here as it exclusively operates on encrypted messages (i.e. starting with IKE_AUTH).


How do people keep track of their employee's privileged accounts?

If you are allowing people to use personal accounts for external services like dropbox, you really have no control and you do not own those. Most services that offer a corporate or business version have the ability to set one or more administrators, and can disable the accounts through this interface.

From a process standpoint, some organizations do this by hand, others have checklists built into the HR management systems with workflows. Ultimately, if the credentials are not tied to AD, LDAP, Shibboleth or some centralized/federated system, you will need to manage these individually. You could use any type of database to track this.

Your organization should develop some type of service management inventory/database. In an ideal world, no third party service is used without management's authorization and these should all be tracked as part of the vendor management process (ITIL, CMMI, etc can provide guidance on the vendor or third party service provider management). From this list you should be able to make a checklist and you could check each checklist.

As part of normal user management processes, you should be doing regular access reviews/certifications to check that all current users should still be granted access. In a more mature organization, you will have processes and a paper trail or database which tracks all access authorizations, changes, and revocations. In this case, you should have a paper trail showing all grants instead of checking the list of all possible systems.

As part of a layered approach, in some cases, you can work with the third party vendor to restrict access to the application from outside of your network. In this way, the ex-employee would have to break back into your network to then access the service. Since in most cases you are likely to have at least revoked their remote access and local network access, this can help to partially mitigate the risk if you do not immediately remove access (but hopefully catch it during the periodic access review/certification).

I am not going to recommend any specific product, but you may want to google for something like "access management software for third party services" or "identity access management enterprise tool".

Partially related to this are tools dubbed "privileged identity management", but this are more generally geared towards managing shared administrator credentials.

tl;dr It's more about developing robust access management and access review policies and procedures so that way you have accountability. You should pick a system that has a strong audit trail and is backed up, a spreadsheet can easily be modified, lost, poorly version controlled, or exposed to unauthorized individuals.


Queues for Mobile Web Application Security Architecture?

This basic concept is pretty standard for web applications, with Presentation Servers in the DMZ talking to Application Servers inside the network that then request data from Database Servers.

Or sometimes there are just two layers, but they are segregated by firewalls or routers with access control lists.

The communications may be by message passing, queues or direct connection.


Can allowing a web application to move, copy and/or delete files outside of the server root be a security issue?

If user input has no influence on the commands or their arguments, there should be no immediate threat.

But it is always a risk, you might be missing something or there might be (i.e., there are for sure) unknown vulnerabilities in the software you're using (e.g., Django).

What I would do to mitigate those cases would be to:

Verify your permissions. Assure your using the minimum privileges needed for those operations you need (maybe Apache's user has too high privileges for what you need, create another user with less privileges);
Whitelist only the commands you're going to need (block everything else);
Look into setting up a controlled filesystem for those operations (e.g., some sort of 'chroot');
Harden your server (look into Grsecurity and RBAC);
Obviously keep everything patched and updated.


Ways of Capturing Mobile Application GET requests

It sounds like that app is using certificate pinning. In this case it would be difficult to to proxy any app comms without first bypassing the cert pinning. You are using Trust Killer but it may not be working correctly.

To properly verify your set up first test against apps you know have cert pinning. My guess is the others you tested did not have this.

What you could also do is de-compile the source and have a look there. There is a quick and nasty tool online here: http://www.javadecompilers.com/apk you may have some luck with. This could let you make some ad-hoc changes of your own, re-compile and get a better run time analysis.


Can Android phone running without SIM card be tracked (localized) by police?

A SIM identifies you with your network operator; it is necessary to be able to receive calls and to bill you for calls you make. Without a SIM, a phone is mostly useless as a phone, but it can still make emergency calls (in most countries). Without a SIM, your cell phone will not normally transmit data to local base stations, but if you make an emergency call, it will identify itself with the cell tower by sending its IMEI. So there is some information identifying your phone that can travel on the cell phone network, but only at your own behest. I don't know how easily the police can access this information.

If you've turned off GSM altogether and are only connected through wifi, it's a different matter. The wifi access point knows your phone's MAC address. Whether (or how easily) the police has access to that depends on who owns the access point.

Beyond that, your internet traffic does not inherently contain information that identifies your phone, but there is a lot of indirect information. Your IP address will pinpoint at least the access point's ISP and your general location, and with the cooperation of the access point owner your access can be tracked back to the access point by someone who is trying to trace your traffic. The content of your traffic may or may not identify you or your phone, for example through browser fingerprinting, or simply because you logged in to some online account.

If someone is in the vicinity of the access point, they can physically locate your phone by measuring its radio signal.


Why are low-entropy passwords considered OK in many cases?

"Cracking" a password on a website is not subject to the same kinds of brute-force attacks as encryption keys. Unless your source is a breached database, the rate at which you can brute force is limited by the website, which can introduce source-based throttling or blocking, attempt limits, raise flags etc. which makes a simple brute force harder to do.

However, if hashes have been leaked and there is insignificant additional entropy, then 8 character passwords are not secure, as @Lie Ryan suggests.


How can Nmap bypass Windows Server firewall rules?

As others mentioned it could be related to the ordering of your firewall rules.

Also modern host firewalls also allow for process/program exceptions so it's possible that during the installation of nmap the installer added a process exception for itself to the windows firewall allowing itself to bypass other rules.


You can prevent clickjacking using the X-frame-options header as you mentioned but a more modern approach uses the CSP header. You best use both: CSP vs X-frame-options

Access-control-allow-origin:* should be avoided on state changing pages or private pages. Since you mention it is "hosted on github" I don't assume it has a dynamic nature and it will not accept request that modify state or show private info. Therefor the issue might be mute. The header allows another website to call your site and make the result accessible to the domain on which that site is hosted.

If you can explain what you site does, it might be clear what the impact is. I don't know if and how you can change github response headers. This post might be helpful

Specific to CORS on GitHub, it seems that all pages now return the wildcard source.


Trying to GET "/iptac-xxxx" not found in nginx log. Is an attack?

IPTAC usually relate to a Cisco Web Security Appliance.
Can be like a cookie insert for a url redirect.


Benefits of a wildcard vs per-subdomain certificates

For websites which dynamically generate subdomains (for example, if users can create their own subdomain for some service), installing a certificate for each new subdomain is far from ideal, because you need to verify the ownership of the domain for each subdomain, followed by the installing of the certificate for each subdomain (which typically also requires a reboot of the web server).

In addition to activating new subdomains, managing many certificates (each with its own expiration date) quickly becomes a major hassle. All in all, this constitutes an increased complexity at the cost of no extra security.

So, in summary, the advantage of a wildcard certificate is in the lower administrative burden.


what are the risks associated with an incomplete certificate chain

Missing chain certificates are not a security problem by itself. That means just because chain certificates are missing an attacker cannot mount attacks he could not do when these certificates were present. But, missing chain certificates can indirectly cause problems which are security relevant.

Missing chain certificates often means that the peer cannot verify the certificate and thus fails to establish the HTTPS connection. While several desktop browser try to work around such problems by using cached chain certificates or downloading the certificates such behavior is usually only restricted to these browser. Most other applications will just fail to connect. In most cases failing to connect is just annoying. But in some environments this can be a serious problems if important data do not get exchanged because of this.

Also, some developers try to work around such kind of problems by disabling certificate validation. Unfortunately there are way too many answers and comments on stackoverflow.com which suggest simply disabling validation in such cases without pointing out the security problems this causes. Because, while this seems to fix the current problem in that the TLS connection works, it also makes simple man in the middle attacks possible and thus creates a huge security problem.


How effective is something like Deep Freeze against boot sector infections?

Forgive me, but the #1 solution for a real-time dependent system is to not let undesignated junk run on it. Users shouldn't be browsing the Internet with an RTOS setup. That needs to stop yesterday.

At least in good theory, Deep Freeze type systems will protect your computer from any permanent modification. They intercept all write activity and remap it. That means that any changes, including to the boot sector, would be dereferenced upon boot. Frozen data is never overwritten, just pointed away from until the system is reset.


How can I audit which type of Block Mode encryption is being used when no source code is available?

Testing for ECB / CBC / OFB / CTR mode is fairly straightforward.  It's also straightforward to see if the mode has authenticated encryption like EAX / GCM (though it isn't straightforward to see which mode of AE).

ECB: have a file with many similar blocks in the plaintext.  Do you see identical blocks in the ciphertext?  (Yes this is similar to Dan's answer, last part of Adnan's answer, but included for completeness).
CBC: Encrypt a file, and then flip a bit in the IV (typically in the first block of the ciphertext); say you flipped the fifth bit of the first block.  Do you see an identical flipped bit in the first block of the plaintext after decrypting?  Similarly, flip a random bit later in the file say the 8th bit in the 10th block of the ciphertext.  When you decrypt do you see the 10th block as gibberish, and then the 8th bit of the 11th block flipped?  Again, consult the modes of operation diagram for CBC decryption and the reason should be clear.
OFB/CTR: Test if you have a stream cipher.  Without touching the IV / Random Nonce (typically the first block), if you alter a bit later in the ciphertext, do you see same bit flipped in the decrypted plaintext?  If so you have a stream cipher; an important difference from CBC is in this case there's no gibberish block.  I agree with CodesInChaos's comment that there's little security difference between OFB/CTR.  If you have the encryption key1 call it K, you could differentiate between OFB / CTR.  E.g., let c[1], c[2] be the first and second block of ciphertext and p[1], p[2] be the first block of plaintext.  Calculate D(K, c[1] XOR p[1]) and D(K, c[2] XOR p[2]), where D(K, c) is the decryption of block c with key K.  If they are consecutive numbers, you have CTR mode.  If D(K, c[2] XOR p[2]) = c[1] XOR p[1] then you have OFB mode.
EAX/GCM - Both are authenticated encryption -- they contain a message authentication code (MAC) and the file will not decrypt (even to gibberish) if the file is altered as the MAC will not be valid with overwhelming probability.

Granted, a lot of this assumes things like you know the block size, but that should be easy to figure out.  E.g., encrypt a very small (1 byte) message.  Then assuming there's no MAC involved, you'll likely create a two block message (IV + one-block of padded ciphertext -- though CTR/OFB may not pad); then encrypt a longer message.  From trial and error, you should be able to find out the block size and IV size.

EDIT: I definitely agree with the excellent point Thomas Pornin brought up.  This sort of reverse engineering could help uncover the block cipher, but doesn't really test security.  There are many backdoors that could have been covertly put in that you can't detect without painfully reverse engineering, by stepping through the assembly.  For example, you could believe you have an Authenticated Encryption block cipher that can only be decrypted with your secret key constructed off your passphrase.  But really the file is encrypted with a random key, that is itself encrypted at the beginning of the file using both your passphrase, and then once with their backdoor key.  Thus, they would be able to decrypt any file you use.  Or maybe the scheme does this same scheme, e.g., at the beginning of the file store the per-file-key to be decrypted using your secret key, but there's only about a billion or so keys (that they know all of them).  Or maybe its encrypted with only your key, but the key derivation function only uses the first ~30 bits of the hash of your passphrase as your key.  Hence, it could be very quickly brute forced with a billion attempts.  Similarly, it doesn't have to be a deliberate backdoor; it could just be improper subtle implementation flaw allowing for side-channel ataacks.

1 This was not assumed for other parts -- there are a lot of ways you could know to enter a passphrase to the decryption system, but not know the key derivation function (or encryption function) used internally to generated the key.


Is there any benefit to encrypting messages with PGP that will be trasmitted over SSL to a REST server?

No, PGP is not needed if SSL is setup correctly.  Of course, it will "add more security", but the benefit doesn't outweigh the hassle of creating it.

If a malicious agent in between would be able to decrypt the traffic (MITM, ...), you could also wonder if somebody would be able to access your web application's environment and use the private key of your generated keypair to decrypt traffic.

If you wish to have your connection authenticated as well, you can always issue client side certificates, and perform mutual authentication; this will give you data confidentiality and integrity.  And is a lot easier than implementing PGP in a web client/app.


It depends on the protection requirements of the website. When you talk about multi-factor authentication, you distinguish between different types of factors:

Something you know (e.g. a password)
Something you have (e.g. an authenticator)
Something you are (e.g. fingerprint)

How many of these factors are required, can be decided based on the protection requirements. If the website is fine with a single factor, proving that you own the authenticator is OK. If the website requires 2 factors (e.g. password AND authenticator), but you are able to log in with only the authenticator, you have found a security defect.

This means the answer is, it depends.

Sidenote: In case your browser is already known to the website, because you successfully authenticated with the same user in this browser before, the requirements concerning the amount of factors might have been deliberately reduced. This is done by some websites to improve the user experience.


Does an unused ftp account pose a security risk?

The short, non-nuanced answer is "Yes". Even if the accounts are unused there is still a risk of brute force.

A longer answer would be "Yes, but you can greatly mitigate the risk".  I know you said you changed to SFTP, but I'm not clear if you've disabled the FTP service completely. A good chunk of the risk here can be mitigated if you're able to (or already have) harden the server by disabling FTP.

Additionally, if these users only have the ability for FTP logon you'll further reduce the risk. It's going to be difficult to exploit FTP accounts if there is no FTP service running and the accounts can only log into FTP.

I haven't run anything on Bluehost so I don't know how much control they give you over the above.


Can Chrome's Incognito mode be disabled?

Anonymous navigation is a confusing term. The navigation is not anonymous, it only leaves less traces on the computer.

Even if you disable that funcionality, the user could instruct the browser to wipe all data, and get the same. Or s/he could make the AppData folder for Chrome read-only, and get the same effect.

There's better ways to do that. The easier is to have a policy signed by the employees stating that all the internet access is logged, must only be used for business reason, and they agree with it. Install a company-wide proxy with logging enabled.


Does Windows require the full certificate chain in order to trust a certificate?

The PKI is based on CA certificates, which are certificates you trust to vouch for other certificates.

You will always have a copy the certificate for the CA. Let's call it "bdxCA"

When Bob comes with a certificate saying "Hi, I'm Bob, here's my certificate signed by bdxCA", the computer looks up his copy of bdxCA, see it did sign the certificate and that it trusts bdxCA for the stated purpose (e.g. user identity).

Now come Intermediate CAs. These are certificates that are able to sign other certificates but you are not trusting directly, but whose trust derives from a "real" CA.

So, you may have bdxCA signing bdx_HR_CA which itself signs Bob certificate. Here Bob should provide both his own certificate as the intermediate one(s): "Hi, I'm Bob, here's my certificate signed by bdx_HR_CA, and you can see that one is signed by bdxCA". You check that it is indeed the case, and accept it.

If Bob hadn't provided the intermediate certificate, it might or might not be accepted. If the receiving side don't have a copy of bdx_HR_CA, they won't be able to validate it, and will thus reject it. However, it is possible that the intermediate CA was imported locally (so it will be able to find it), or perhaps Alice had already shown her own certificate as well as bdx_HR_CA one, and thus the later had been automatically stored. Moreover, in some cases certificates include a url from which the parent (intermediate) certificate can be downloaded, and certain clients are able to helpfully download them.

All of this leads to the case that when intermediate certificates are missing, they may or may not validate, depending on the software used, and the previous machine history, all of which results in inconsistent problems, as they only sometimes fail.

Then, it is also possible for a CA certificate to also be signed by another CA. This is generally done when a new CA may not be trusted by all clients. Signing the CA by another one that they do trust allows them to trust certificates emitted by this new CA (by treating it as an intermediate one).

In your case, you have imported the CA certificate, but you probably haven't marked it as trusted, so Windows doesn't have a route to a trusted CA to verify it.

Finally, as your use case is about at VPN server and VPN user certificates, please note that these generally use their own CA, with the server CA provided within the VPN configuration. In which case, it doesn't matter if it's trusted by windows or not, as the VPN client will simply check if the VPN certificate is the one it is expecting it to be.


What's the payload of this phishing campaign (which I clicked)?

The point is to draw you into their web of interactions. The more you tell them non-private info, the more likely you are to answer with private info when they ask. Also, the link itself might try to infect your browser/device.

Clearing your cookies and data is not going to do anything. I'd make sure your Chrome was already up-to-date (there was a major security patch this week), and run scans on your device.


What exactly could we get as an attacker if Kerberos Pre-Authentication is disabled?

You wouldn't ever try and brute force the TGS session keys, as they are almost certainly going to be randomly generated in any implementation out in the wild. This isn't strictly true with older versions of Kerberos (v4), but there aren't, or shouldn't, be any production systems still running older versions.

The only attack that's practically possible is attacking the AS-REP, that is, the response that contains the TGT, because the response is encrypted using the users long term credential, which is their password. If you can bruteforce the key and decrypt the response you now either know the password, or the derivation of the password, which is just as useful. You aren't breaking the krbtgt secret in any way.

In principle this also applies to attacking the tickets in TGS-REPs to get the service principals secret, but you're not going after the session keys. Instead you're going after the tickets themselves. It's basically the same bruteforce attack. Find the key that decrypts the ticket and you've found the service principals long term credential, which is their password. This is however impossible without already knowing the user credential since you need the long term credential to get the session key to decrypt the response.

Certain service principals like krbtgt have long randomly generated passwords so the likelihood of bruteforcing that key is nil.


On a openSSL server, is it possible to see what kind of ciphers are supported?

Is there a command for this?

openssl ciphers 'ALL'

will list all the encrypting ciphers.

openssl ciphers 'ALL:COMPLEMENTOFALL'

will list all ciphers.

If you want to confirm the list, you could use a script to cycle through each cipher and try to connect a tls-client with that cipher. You might also want to cycle over version as well, this is illustrated in this example bash script


SSLV3.0 Poodle Man-in-the-Middle scenario

Updated to better explain what's going on after referencing the original paper.

Since it's block encryption and the attacker is tricking the user into sending requests, the attacker can force the requests to 1) have a full block of padding and 2) have a block where a specific byte of the secret cookie is at the end. Since the block cipher decryption is the same per block across a single stream, the attacker takes the whole block of padding and replaces it with the whole block ending with the specific cookie byte then sends it off to the server. If it gets accepted, the attacker knows that the last byte of the cookie block decrypted to 00000111, which (through some math on the encrypted values) allows the attacker to calculate the unencrypted byte of the cookie. If it doesn't work (which it won't 255 times out of 256), then the attacker needs to force the user to submit an entirely new request (which means an entirely different round of encryption, so it'll have completely different encrypted values even if it's the same unencrypted data). Only after it's accepted will the attacker change values, and what he/she will change will only be the part of the cookie that's in the last byte of the block he/she is swapping.

Old post:

Since there are 28 = 256 different values a byte can be, and since the attacker can't predict what the output will be, he/she must guess until that last byte has the one value that is valid, namely a value of 7.

By the nature of the XOR operation, if one input is static then there is exactly one value for the other input that will produce a desired output. So if the c7 is 01010101, only an e7 of 01010010 will result in 00000111. The attacker can't know c7, but he or she can change e7 (since that's just the value of the byte in the request) until the server doesn't return an error.


What type of attacks will a SMTP server face if it does not have ratelimiting while sending mails?

One of the difficulties in securing SMTP lies in the protocol itself, specifically the admonitions in RFC 5321 which give proscriptions on timing out a session.  A faithful implementation provides no facility for timing a session out.  Ideally one would want to ignore those recommendations, and set a session timeout for the mail session.  This will prevent for example any attacks where long delays are used to send data character by character with large mail sizes.  For example if you have a mail server with a 10MB mail size limit, it is fairly easy to write a script which delivers a fake mail to your server and writes a Lorem Ipsum message, one character at a time up to the 10MB limit, but delaying each character by 1 - 2 minutes.  Theoretically without a session limit such a mail session could run around 10 million minutes.  So now run a script that simply starts bots that do this from hundreds of places on the web, and pretty soon the bots will have all your connections tied up (assuming you have connection limits, or are using a connection pool).

Ideally, one would set up a timer from the time the DATA command was issued to the time that the "CRLF . CRLF" was issued.  Something like 5 minutes or so for the whole data to transmit should be reasonable.  And violate the RFC and simply drop the connection if it exceeds that timeout.  Well behaved clients will never come close to that limit and even people using the command line terminal ought to be able to send data within that time frame presuming they know how to type.


Is it advisable to fully record terminal interaction for incident response?

Yes, it's definitely advisable. In analysing an incident, you'll always want to have as much information as possible. Having too much information is better than not having enough as you don't want to be guessing links between actions.

For reviewing an incident, you'll want to know who did what when. In order to do this, you'll want to know the authentication so you know the who, you'll want the commands entered so you know the what and you'll need NTP sync'd so you know the when.

Depending on the system, some activity may not be captured in full when a user with privileges drops to a shell prompt. In these instances you may want to implement additional controls to prevent this or add software to detect it.


Can fully homomorphic encryption be practical?

There is no proof that FHE cannot be implemented efficiently. It is just that, right now, we do not know how to do it. With currently known algorithms (Gentry's algorithm, with a few known optimizations), it would be extremely slow, which means impractical (and quite far in the "impractical" realm, actually). FHE would have to become thousands of times faster than what can be done today, in order to achieve some kind of generic practicality.

Of course, there are a few specific applications which can already make use, in a very practical way, of homomorphic encryption. Typically voting systems, such as Helios Voting -- these do not need fully homomorphic encryption, and can work with a plain, efficient, partially homomorphic ElGamal.


Disabling built-in Wi-Fi adapter and protecting Wi-Fi's MAC address on a laptop

The MAC address is specific to a network interface (e.g. your WiFi adapter) and is used for local routing of packets. Every packet sent by a given interface will bear that address, so it cannot be assumed to be secret. On the other hand, knowing your MAC address does not give a lot of power to an attacker -- at best, that attacker could mimic your MAC address so as to fool stupid WiFi access points configured to allow only computers with specific MAC addresses to connect.

So there is no need to be concerned over revealing your MAC address, but, also, your MAC address is not revealed until you actually emit packets.

Shutting down your built-in WiFi, when you don't use it, is a good idea; otherwise, an attacker could pose as an open access port and induce your laptop to connect through it. As a general rule, the Internet is a wild place and you must assume that every single machine out there is hostile -- however, there is no point in actively helping attackers to mount easy Man-in-the-Middle attacks. Most laptops have a "kill WiFi" button (so that the machine may be safely used in airplanes); this might work for you. Alternatively, try removing the driver for your WiFi adapter (that's brutal but it should work).


Here is another diagram from Layer3

So... the server sends it's certificate to the client to validate it's identity and the client also does the same, after this comes any other inner authentication protocol if required.

The MSK (Master session key) is derived from the TLS Master Secret via a one-way function. It is in this MSK that the PMK is generated.

The MSK is divided in half, the first half called Peer(STA/Client/Supplicant) to Authenticator Encryption Key (32 octets) is the PMK or Enc-RECV-Key and the second half is the Authenticator to Peer(STA/Client/Supplicant) Encryption Key (Also 32 octets) or Enc-SEND-Key.


Does it still make sense to encrypt data over SSL?

It mainly depends on the risks you want to mitigate. If you can (reasonably) trust all the infra around the server, and if you do not need to protect this data from a corporate deep inspection proxy, you can trust the SSL/TLS encryption layer.

You should normally only add another encryption level in the following use cases:

you are at work behind a corporate proxy with deep packet inspection and the data is sensitive enough to require being hidden to the local network support team
the data should never be on decrypted form on the server. This can be used if you cannot trust the server admin team

An example of the latter use case is the exchange of S/MIME encrypted mails. You still use TLS to protect the communication (mainly the credentials) but only the final recipient will be able to read the message: the mail server admin only finds a crypted payload.


Limit of 256 bit drive encryption? 512 needed for large drives?

AES is a block cipher. Wikipedia says:

  The winner of the AES contest, Rijndael, supports block and key sizes of 128, 192, and 256 bits, but in AES the block size is always 128 bits. The extra block sizes were not adopted by the AES standard.

So AES 256 means Rijndael with a 128 bit block size and a 256 bit key.

The maximum size of data a block cipher can safely encrypt under the same key depends on it's block size, because the more blocks you encrypt with it, the larger the chance that two blocks will be the same. This will start leaking information the more it happens, so you want to avoid it.

However, the key size does not affect the number of blocks you can safely encrypt. So even if there was an AES-512, it wouldn't do anything to increase the maximum size of the plaintext you can encrypt.

Since AES block size is 128 bits (16 bytes) and thanks to the birthday paradox you can expect an identical block appearing after having encrypted about 2^64 (the square root of 2^128) blocks, so you might start to worry when you get in the region of encrypting 2^64 * 16 bytes with the same key.

Of course, that's not a hard limit. It's just that the likelihood that you're leaking information useful in breaking the encryption increases. You might be totally fine encrypting way more than that, or you might want to worry much earlier than that. But AES is completely fine for encrypting 4 or even 16 TB of data.

As for AES 512, maybe you're refering to a 512 bit key that gets split into two 256 bit parts for LUKS in aes-xts-plain mode? The man page of cryptsetup states:

  For XTS mode you can optionally set a key size of 512 bits  with
   the  -s  option.  Key  size for XTS mode is twice that for other
   modes for the same security level.

This means that in order to get the security of a 256 bit key, you need to specify a key size of 512 bits for XTS. You need double sized keys because in XTS mode AES is used twice, and each invocation uses one half of the key (see Explanation of the XTS Encryption Mode).


Can custom elliptic curves be used in common TLS implementations?

The NIST has "defined" 15 "standard curves", specified in FIPS 186-4. Actually, they did not define them themselves; they inherited them from SEC. These 15 curves aggregate into 3 groups:

The P-* curves work in a "prime field" (point coordinates are integers modulo a prime p).
The B-* curves work in a "binary field" (point coordinates are values in GF(2m)).
The K-* curves work in the same fields as the B-* curves, but have a special structure which allows for faster computations.

NIST found out that there was a huge reluctance to implement support for these 15 curves, let alone for "general" curves, for a variety of reasons:

The involved mathematics are felt to be "hard" (that's harder to grasp than RSA or plain Diffie-Hellman).
... even more so for curves in binary fields.
While it is possible to write "generic" curve-handling code, code which targets a specific curve is often simpler to implement and faster. In particular, the P-* curves work modulo prime values whose format makes implementation more efficient (fast modular reduction).
There have been recurrent and long-standing claims of patents, making the use of elliptic curve "risky".
... especially for curves in binary fields;
... and more generally for generic curves chosen to have some characteristic which is beneficial to implementation. It is not known whether a curve can be patented (as opposed to an implementation technique supported by a special curve structure), but uncertainty already does powerful dissuasion.

Thus, people were wary of implementing generic support for elliptic curves, because it seemed to be hard, detrimental to performance, and a legal minefield. Sticking to a few of the simpler curves seemed easier, faster and safer; and that's what happened. NIST (well, NSA) formalized this trend as their "suite B" cryptography suite, which mandates implementation of exactly two curves: P-256 and P-384.

In SSL/TLS and in X.509, arbitrary curves may be used. However, most implementations won't support arbitrary curves. OpenSSL supports all 15 NIST curves, but not arbitrary curves. Firefox supports only P-256 and P-384; I am not sure Microsoft's code (Windows, hence Internet Explorer) will accept more than that either (maybe P-521 as well). If you try to use any other curve than P-256 or P-384, then you will encounter interoperability issues (more issues than what you already get by trying to use elliptic curves at all). Some standard writers, feeling that they must "be practical", have fully admitted this fact, and just banned the use of other curves, as you see in RFC 5480.

Generating your own curve is not hard, but substantially harder than generating your own DH parameters. It involves point counting with Schoof's algorithm or a variant thereof. You won't be able to slap together a curve generator in one hour and a hundred lines of Java code, whereas producing DH parameters can be done under these constraints. The computational cost is also higher (you will still get a nice curve in a minute, but not in 100ms). To be brief, people don't do that often, or at all.


Something causing Sonicwall to throw Smurf Amplification Attack Warning?

Have you verified that this is in fact a smurf attack? Are you receiving a lot of traffic?

Or is the IP address from the firewall actually your ip?

It would help to see a packet dump of the actual "attack". Someone has to be the victim here, and if it is you, you should see a flood of ICMP messages coming your way.

smurf.Powertech.no has a register of networks that has not been properly configured thus allowing the smurf attack. Quote from their site:

  The SAR lets you probe Internet connected IP networks to see whether or not they are
  configured in a way that will allow perpetrators to use them for smurf amplification.

I think you should definitely start a packet dump ASAP and see if you can figure out where the traffic is coming from. It might be hard as a smurf attack is in theory spoofed, but a packet dump could perhaps give us some vital pointers.

Tcpdump command that might work in your case:

tcpdump -w test.pcap udp port 8


This would be a "Drive-by" attack, where the simple act of visiting a website from an initial click allows for a successful hack of the client.

Usually escaping the sandbox, getting code execution and privilege escalation is the result of combining multiple flaws to result in the desired goal.

This year, 2018, the pwn2own event held in March - awarded prizes for popping Edge, Safari and Firefox on desktop platforms.

So, in theory in 2018 it was possible… also if you look at CVE Details website for Chrome, Edge, Firefox and Safari you'll see the stats for 2018's CVE in those browsers. Given that these are just the known vulnerabilities it seems likely that drive-by are still possible.


What is the expected TLS traffic from Jenkins?

Some versions of Wireshark have the SSL decoder just on port 443, so I was wondering that if your Jenkins SSL traffic is on port 8080 may be that is the reason. If is not may be you can upload the pcap file so people could determine better the problem


How to use encrypted internal strings and config?

You are right that the key will always have to be availabe to the program that uses on-the-fly decryption of some of it's parts. There is no way around that, which means that this is the kind of security that protects you against your little sister, but not against a determined attacker (paraphrasing Schneier here). It's impossible to keep a capable attacker from finding the key.

For viruses, encryption is useful for another reason: Virus scanners scan for specific patterns, and if you encrpyt large parts of the virus, using randomly generated keys, much of the pattern matching becomes useless. The only thing left to match against is often the initialization code and the decryption function, and there are tricks to change the binary fingerprint of these parts, as well.

The way this could work is that when a virus infects a new system, it creates a copy of itself, but uses a different encryption key and shuffles around various parts of the decryption function and init code, so the copied virus doesn't look like the original at all.

What you read might be related to that: If you encrypt config strings, it becomes much harder to simply grep for a string to detect a specific program. But it's hard to tell without a reference to the document you mention.


Securing Web Contact Forms Against Spams

You will never prevent all spammers; not with a CAPTCHA or any technical means.  Some spammers hire "smurfs", which are large numbers of people who each send one spam per web site, but each person spams hundreds of sites.

The motive of the spammers is likely to use your site to deliver their spam in your response emails.

If your response to the contact form is to repeat whatever the user typed, then the message your spammers enter into your contact for will reach their target audience.  Your ordinary response email looks like this to you:

To: Sibidharan@example.com

Thank you for your inquiry.  You wrote:

"I have a problem ordering widgets,
 can you fix my problem?"

We will process your question promptly.
Thank you,
Example.com staff

The spammers want to send their spam to a victim.  They go to your Contact Us page, where they put in the victim's address as their address.  In your "Please enter your message" field, they put in their spam message in the victim's language:  "BUY OUR CHEAP DRUGS SEND EMAIL TO CHEAP AT DRUGS DOT COM".  They then submit their comments.  The victim will receive this email from you:

To: victim@contoso.com

Thank you for your inquiry.  You wrote:

"BUY OUR CHEAP DRUGS SEND EMAIL
 TO CHEAP AT DRUGS DOT COM"

We will process your question promptly.
Thank you,
Example.com staff

But the victim does not speak English.  They will only see this:

To: victim@contoso.com

blah-blah-blah-in-English

"BUY OUR CHEAP DRUGS SEND EMAIL
 TO CHEAP AT DRUGS DOT COM"

blah-blah-blah-in-English

To fight this, have your emailed response be generic:

To: victim@contoso.com

Thank you for contacting Example.com.
Your email is important to us and will be processed within 48 hours.

Example.com staff

That way whatever the spammers type will never reach the email clients, hopefully taking away the motive for the spammers to use your service.  Your real response, of course, could include the original question, but your service agents would not be responding to obvious spam.


How to build arbitrary code without risking the server?

This isn’t a simple answer. There are tools specific to different operating systems like Windows or Linux that perform file integrity monitoring. Be aware that things like system or build tool updates can create a lot of false positives.

There are some things you can do around checking code but that will generally add a lot of management overhead. Are these scripts coming from untrusted sources or do you want to double check that internal developers aren’t doing anything bad?

One of the easiest things to do is network segmentation. Make sure the box is isolated in an environment where it can build properly but connections originating from this box can’t connect to other systems.  This will help even if someone does manage to sneak something malicious in there is isn't a path for it to get out compromise other machines.


Can a scanning id system like trusona really be secure?

From the demo, it looks like they've built something pretty similar to every other PAM platform, except that it uses a smartphone camera and an app to perform the validation. The use of a driver's license in the latest version is a cute add-on, but it will probably meet with user resistance.

Based on what I saw in their videos, the basic architecture looks like this: users establish their account with a third party validation provider (Trusona) and install the app, which is linked to the account with a certificate pair. When you attempt to log in, a push notification is sent to the phone associated with your account and you take a picture of a one-time password in the form of a QR code. The app verifies the OTP with server and logs you in, fulfilling the "something you have" and "something you know" roles with the phone and QR code, respectively.

This isn't any different than any other PAM system, really. So as far as security goes, it's pretty okay. You're right that in an ideal world, you'd have three factors for authentication, but for the vast majority of people, this type of two factor centralized authentication would be fine. I wouldn't be terribly surprised to see Trusona or another similar platform popping up on more sites moving forward.

The largest issue I have with it is trust with the third party. If you look back to the RSA breach in 2011, you can see the kind of problems having a single large third-party validation system can have. When the SecurID seed was stolen, it became possible to generate valid credentials on the platform, bypassing the proposed security. Trusona could easily suffer the same fate, but then again, so could any other authenticator.


Is a password protected SSH key necessary on an encrypted system?

Yes.

File-system and hard-drive encryption are security controls which defend against a specific threat, in this case it usually protects the data when the system is physically taken.

When attackers access a system while it's running via something like a vulnerable web application or through some other method they are effectively accessing the filesystems locally with user permissions of what ever application they compromised or in some rare cases they take over the kernel. When this happens the controls which keep the filesystem or disk encryption are effectively bypassed and the "user" can grab whatever files he or she has access to via the compromised account. Likewise there are many other flaws which allow attackers into systems but the point is that the two security controls you mentioned protect from different attack vectors and are both important to create a Defense in Depth strategy.

The security control of the password-protecting your SSH key is still valid and does offer additional protection that the file-system or disk-encryption by itself does not offer especially in the case of an attacker who has access to your system remotely. In this scenario the attacker would take or use  a copy of your key and instantly have access to your Git account.