While the other answer focuses on modifying the exploit itself, you can also modify the transport of the exploit, so that the IDS will not detect it (Disclaimer: some of this points to my own research).

Some examples on how to do this on the application layer with HTTP (i.e. for drive-by-downloads while browsing the web etc):

Use a valid but less common HTTP compression method, which is supported by the browsers but often not by the IDS. Often a simple Content-Encoding: deflate is enough, like with ZScaler or Comodo Webinspector or Sophos UTM (fixed).
Combine HTTP compression, e.g. use a Content-Encoding of deflate, deflate or gzip, deflate. IDS like Bro, Snort, Suricata or even VirusTotal only look at the first or last compression scheme, while browsers like Firefox or Google Chrome accept content which is compressed multiple times.

Similar evasions can be done by playing with content-transfer-encoding when sending the malware by e-mail.

And then there is a nice research about evading IDS at the transport layer. There is a paper about Evading Deep Inspection for Fun and Shell and also a video from Blackhat 13.

And of course you can also modify the exploit itself. Here is a nice description of how to modify existing exploits so that common AV will not detect them any longer.

Other evasion techniques use social methods to evade IDS, like putting the exploit into an encrypted ZIP file, attach it too a mail and write the password into the mail too. If done well the victim will be seduced to open the file with the supplied password just to get the content (like the alleged salary lists of his company or similar traps). Because the password is not known to the IDS it can not detect the malware.


Managing keys generated with insufficient entropy

Virtual machines have virtual hardware, but this does not necessarily means that they are completely devoid of entropy sources. In particular interrupts: while the VM has no real interrupt generator hardware, its OS still receives such "interrupts" as part of the emulation of hardware. For instance, when you connect to your VM through, say, SSH, network packets still flow back and forth, and each incoming packet triggers an emulated interrupt in the VM. The entropy derived by the kernel from such an interrupt comes from the exact time of appearance of that interrupt, which, in this case, is a function of the real arrival of the packet on the physical network interface of the host system. The process from incoming packet to interrupt is more convoluted than in a non-virtual machine, since the host and the VM layer lie in between, but entropy from the physical world is still made available to the VM kernel.

A much more pressing problem for VM and randomness is VM cloning. You may want to install and configure a complete VM, then make a snapshot and clone it in order to easily create several new already configured VM. Unfortunately, this means that all the clones start from the exact same internal RNG state. Once booted, they begin to diverge as each accumulates its own "random events" (even though the hardware is emulated, emulated hardware events still indirectly come from true hardware random events, as explained above). The divergence may be slow in computing terms (it could take several seconds, and that's very long for computers that can do billions of operations per second).

The most complete method to fix that is to enforce randomness by seeding each VM with a seed obtained from some other random source elsewhere; this is as easy as writing some file into /dev/random. This may be desirable if you clone VM; otherwise, this is probably useless (but it won't harm anyway). Note that this is needed only once per VM: normal Linux distributions will generate and save a "seed file" upon shutdown and reuse it at next boot, so once a VM has been seeded it stays seeded.

As for your #2 solution, take note that the difference between /dev/random and /dev/urandom (in Linux) is not exactly what you state. /dev/random will block if it estimates that its internal pool has not enough entropy; but it also consider that its pool is depleted upon usage. Blocking before enough entropy has been gathered is fine; but the "depletion effect" implies a lot more blocking, and that one has only very flimsy scientific basis. It is a known defect of Linux's /dev/random. A much saner behaviour is what you get with FreeBSD's /dev/random (and, by extension, Mac OS X): that one will block until enough initial entropy has been gathered, then it will produce as many bytes as you wish with a cryptographically secure PRNG, without blocking. Note that FreeBSD /dev/random and /dev/urandom are completely identical (and this is good).

Anyway, even Linux's /dev/random maniacal behaviour with regards to entropy depletion will be fooled by VM cloning. So insisting on generating keys with /dev/random will not only make you wait for inordinate amounts of time; it may also fail to actually achieve the desired level of randomness in the presence of VM cloning.

To sum up, your #3 solution is the right one.


What kind of attacks can happen on port 80

WAN or LAN?

  would exposing just 80 or 443 still compromise the security?

Yes it would - there could be numerous vulnerabilities in the web app that an attacker could use to gain control of it.

  Can a hacker push bots or take control of the server and in turn reach the internal network?

Yes, once they have control of the web server they might be able to leverage that access to gain control of other machines. It very much depends on which other internal servers that machine can communicate with.

  What kind of security measures need to be taken given this approach?

I would recommend you hire a security firm to pen test this. Before deployment you could arrange for you application to be audited in a separate environment.


Signal: Secure way to transfer images out of encrypted chat?

As @MiaoHatola pointed out in a comment, the obvious solution is to use the Signal Desktop Client (Chrome App) which allows you to be signed in and receive messages simultaneously on your phone and laptop.

If you have set up the desktop client as a second device (scanning QR code to set up keys) then you'll be able to see all images sent to your phone from there. When you click on an image, there is a download button and it lets you choose the location, which is ideal as you can send the image directly to an encrypted container.

Note that the other solution employing AirDrop is still needed in several common scenarios:

Desktop client was not been set up yet when images were sent, so AirDrop is needed to retrieve such older content.
Desktop client is undesirable for any reason (shared laptop, insufficiently trusted system etc.)

Using the desktop client has several important benefits:

Target location can be controlled so the file never sits unencrypted on disk.
No need to set up iOS/iCloud to enable AirDrop.
Obviously works with Android/Windows unlike AirDrop which requires a full Apple/macOS/iOS workflow.


What should be included in the ground rules for an attack review?

I think your document is great.

If you forced me to criticize something, I would mention two things:

Understanding the policy that you want to enforce takes some doing: it requires reading a bunch of code and regexps.  I don't know if that's avoidable.
The attack scenario seems a bit limited.  The ground rules don't seem to cover the case where the sanitized HTML fragment (e.g., from an eBay seller) is composed together with some trusted HTML (from eBay itself) to form a HTML document, and doesn't say what security properties must be enforced in this case.  For example, in that kind of situation, the reader is forced to guess whether you are trying to protect the confidentiality of the rest of the page.  If the sanitized HTML fragment can somehow discover the value of other secrets stored in the same document (e.g., CSRF tokens found in hidden form parameters in the trusted part of the document) and exfiltrate it, is that an attack?  I suspect yes, it is.

But these are minor criticisms, and I think the ground rules posted are excellent.


What could be recovered after an interrupted ransomware attack?

In case of ransomware, you would be able to recover:

What hasn't yet been encrypted, obviously.

What hasn't been overwritten, using specialized file recovery tools. These file recovery tools detect removed file systems and files by analysing the contents of the unallocated space. As it uses the data (former contents of a file) to determine whether it once was a file and encrypted data won't have such patterns, it's not a surprise it won't be able to recover removed encrypted data.

Everything from the backups. Backups are the best weapon against ransomware there is! However, if the backups are stored somewhere the user has write access to, they may get encrypted by the ransomware, too.
My recommendations for a good backup solution:

pull instead of push
use incremental backups.


What is this NAT rule forwarding UDP port 1052?

Iana.org port list includes 1052 tcp/udp as a Dynamic DNS linked port.  This may make sense if you consider that DNS port is 53 traditionally, and 52 is close, as is 1052.  This is how ports are selected when people try to choose a different port to make access less than trivial but associate it with some service (like 8080 instead of 80 or port 81 instead of 80).  Chances are someone selected 1052 as a DNS linked port.

Also, chances are you played with DDNS in the past.  Just guessing.


New user with Chinese name appeared on MacOS. Hacker?

I would doubt that's a hacker as the most successful attacks are through social engineering schemes. Few "completely technical" attacks are successful. There's always a flavor of inadvertence by the user and a bit of information security malpractice when attacks are successful.

Now, the account you're showing could be five things.

You let another person use your Mac and that person created an account to separate his/her archives from yours.
You hired a local IT technician who created an account to troubleshoot your Mac.
You rely on cloud managed services, e.g. Azure uses ADAL token (jwt) authentication with an implementation specifically on objective-c (XCode is a dependecy)
The network services at your job rely on Cloud SaaS (Software as a Service) solutions such as Microsoft Office Subscriptions (among other types of software) that uses ADAL token-based authentication.
Some programs create accounts. You may have installed a program which created an account as part of the installation process and such program last used token-based authentication on October 23 2018 at 18:47.


Is there a standard, storage algorithm or protocol for fingerprints?

AFIS is the name of rhe Automated Fingerprint Identification Service, and NIST is the federal agency responsible for technical standards. Search Google for "site:nist.gov afis" and you'll find this link: http://www.nist.gov/oles/afis_interoperability.cfm

From it, it's evident that law enforcement agencies are still struggling to create interoperable systems, which strongly suggests that specific standards you are looking for are still fairly rudimentary. But it also lists progress that's been made.


How to enforce software updates on workstations?

There are multiple vendor products that exist to fulfill this purpose, and unfortunately we have to use more than one of them.

They are not foolproof; Microsoft SCCM may think we don't have any versions of Adobe Flash installed older than X.Y, but then (another product) finds a slew of them, while also missing versions of Internet Explorer below Y.Z.

(I think the divide comes, like all Microsoft solutions, where Microsoft products work best with Microsoft products but not third-party products, and third-party products work best with third-party products but miss the mark on interfacing with Microsoft products. Also inconsistent version string parsing across solutions)

What it comes down to is having some sort of agent on every local workstation that reads from the respective registry and reports software versioning information to a central server. From the central server you get an overview of what percentage of your infrastructure is up-to-date, and what remains vulnerable.

In a separate workflow, another server (something like WSUS, but again, the Microsoft divide rears its head) then forces update agents on the non-compliant workstations to update within compliance during the next update window. Automation tools like Puppet and Chef can be deployed to achieve something like this cross-platform; it's a simple problem with well-documented solutions.

Do NOT leave it up to users to diligently update. They won't, even under threat of firing.


What alternatives to IPSec for diversifyed redundancy?

If you're looking to provide redundancy between sites, you're right that a TLS would be a viable solution for an extra security protocol and a 4G connection has the potential to be a form of redundancy for the site-to-site connection.

Your question isn't really clear on what you're asking for specifically, because HTTPS and 4G work on entirely different levels. If you're talking about protocol redundancy, depending on your use case, you could easily use another encryption technology such as TLS or SSH to connect the two sites. If you're wanting connection redundancy I'd recommend using a secondary line from a different ISP or like you said, a 4G connection to maintain the connectivity in the event of your VPN having downtime. Obviously you can combine the two since, like I said, they work on entirely different levels. For example; you can get a 4G connection and use TLS over it.


Does Ettercap exploit the Hole196 vulnerability?

ARP poisoning is basically when you declare your MAC address is responsible for an IP address, I think usually the router. So you receive all the victims packets in a "man in the middle" type attack. I read that WPA2 encryption happens at a layer below that of packet routing.

Google is your friend, there was already  a post regarding this on here: Is WPA2 WiFi protected against ARP poisoning and sniffing?

Also read this: http://community.arubanetworks.com/t5/Community-Tribal-Knowledge-Base/Analysis-of-quot-Hole-196-quot-WPA2-Attack/ta-p/25382 it explains why exploiting the Hole 196 vulnerability is not required to ARP spoof on a WPA/WPA2 protected network.


How can I get the IP address for a Tor Hidden Service (HS) with a .onion address?

It is not possible to get the IP address of a Tor hidden service.

For a normal Tor circuit, the client knows the IP of the server, but the server does not know the IP of the client.

The idea behind hidden services is that when both a client and a server are Tor-enabled, it's possible to build Tor circuits in both directions and hide both the client and server IP (by using intermediate nodes).

The protocol

Setup

The hidden service picks N introduction points, builds a Tor circuit to each, and communicates its public key
The hidden service advertises these introduction points and its public key

Connecting

The client chooses an entirely new relay called a "rendezvous point", builds a Tor circuit to it, and tells it a newly-generated one-time secret
The client contacts an advertised introduction point over a Tor circuit and tells it the rendezvous point's IP and the one-time secret, encrypted by the hidden service's public key
The introduction point relays this encrypted rendezvous point and one-time secret to the hidden service over the existing Tor circuit
The hidden service decrypts this data, builds a Tor circuit to the rendezvous point, and tells it the one-time secret
The rendezvous point now relays information between these two Tor circuits

Information

This is what IPs each actor knows after this process:

The hidden service knows the IPs of its introduction points
The client knows the IPs of the hidden service's introduction points
The client knows the IP of the rendezvous point
The hidden service knows the IP of the rendezvous point

Essentially, at no point is a Tor circuit built directly to the hidden service, the hidden service always builds its circuits outwards. Therefore, its IP is never revealed.

References: a high-level description of the protocol can be found in Tor: Hidden Service Protocol, while a more detailed description can be found in the original design paper Tor: The Second-Generation Onion Router.


How to safely show some text on a webpage?

There is no magic way to safely display text on a webpage.  Either it is safe to display or it isn't, and which of those buckets your data falls into depends on your threat model.   What specific threat are you wanting to protect against, and what is the risk of the threat being utilized in an attack?  To counter the risk, what is the value of displaying the data to the user?  Is it important enough that they see the data that the value outweighs the risk?

In the case of LassPass, the entire application is designed to allow you to manage passwords.  Sometimes that means you need to see the passwords in plain-text.  It's an important feature of the app, and thus, worth the risk of a shoulder-surfer discovering the password.  For most other applications, there's not really much value in displaying a plain-text password to the user, so displaying it wouldn't offset even small risks.

So, you have to decide for your use case is the value of displaying the data to the user greater than the risk, or not?

Beyond this, it's worth mentioning that there is a third way.   You could leave it up to the user.   You could ask them (via a checkbox, or a link, for instance)  if they want the data to be displayed.  Then it's up to them to determine if the value of seeing the data outweighs not only the general risk, but the specific risk at that instant.  (They might choose differently if using a computer at home vs. a kiosk in a crowded mall, for instance.)  So you could default to the safer option of not making the data display, but give the user the option to override that default.  Realistically though, there needs to be significant value in displaying the data for you to even display it at all.  Generally in the specific case of displaying a user's password in plain-text, that value simply doesn't exist.


As Morgoroth pointed out, nmap.org/submit is your friend in this case.
However, you can also try

Using the --osscan-guess flag to more aggressively guess the OS (lower confidence interval)
Try a different type of scan (null, ack) using the -sN and -sA flags
Sometimes using the -A flag will give you something under "service info" that you can use to imply the OS.


How does the use of Microsoft-branded Azure products affect my privacy policy?

You are a data custodian of your customer's data. The fact that you are using Azure means they are also a partner with you in data custodianship. For you to accurately describe what that means you either need to

Include all the terms of the Azure privacy agreement into your agreement, understanding that these can change rapidly without notice.
or
You need to clarify that your policy is X and that your service runs on Azure who's policy is Y.

If it's an option the 2nd option will be the easiest way to resolve the problem with Azure's ever-changing privacy terms.

Do keep in mind that Azure's policy may also vary by jurisdiction and that you need to keep track of that and also which jurisdiction's laws apply to each of your customers.

Useful Reference: https://azure.microsoft.com/en-us/support/legal/


Buffer Overflow : segmentation error at 0x90909090

You need to pivot the execution into your nop sled. Usually done by overwriting EIP with the address of your payload on the stack or using a gadget like jmp esp.


Is this a threat if website to connect to is in clear in the TLS SNI extension or when using an HTTP proxy?

Isn't it a threat that anyone can see my secure website?

TLS was designed to protect the application payload. It was not designed to protect the meta information of the connection, i.e. the domain name, source and target IP address, number of bytes transmitted, timing of traffic etc. There can definitely be a privacy risk when somebody is getting these information, but to protect the privacy was not a design goal of TLS. The goal was instead to protect the application data against sniffing and manipulation.

The target domain name in the ClientHello (i.e. SNI) is needed by the server to find out which certificate to provide in the case the multiple domains and certificates are provided on the same IP address. It is similar to the Host header of HTTP, only that it is available before the encryption starts so that the proper certificate can be provided inside the TLS handshake.

The domain name is not only visible in the ClientHello. Until TLS 1.2 the certificates (containing the domain name as subject or subject alternative names) where also sent by the server in clear - this was changed with TLS 1.3. There is also a way to encrypt SNI - ESNI is supported by several clients and servers already. But the same information also can be determined by associating DNS requests with later TLS connection to a specific IP address - unless DNS is protected to using DNS over HTTPS or similar technologies.

  ... why there is a need of HTTP connect packet when we have the SNI field from where proxy can find out where it needs to connect?

The ClientHello is only send after the tunnel to the server via the proxy is established. To establish the tunnel the proxy needs to know the IP address of the server. In theory the client could put the target IP address in the CONNECT request instead of the domain name. But a proxy is often used in setups where the internal client has no access to the external DNS at all, which means that the client might not be able to provide the server IP address and that the proxy must resolve the domain name.

In theory a proxy can be configured in a transparent mode where the client tries to connect directly to the final server (i.e. no CONNECT request) and due to some firewall magic these packets get redirected to the proxy which then figures out the real target by analyzing the ClientHello. And this kind of setup is not uncommon in practice. But such redirects does not work that reliable if HTTPS is used on unusual ports (i.e. not 443) since the firewall would need to first detect that HTTPS is used in the first place (using Deep Packet Inspection) in order to properly redirect. And these such DPI analysis is more expensive to do and the heuristics can also go wrong. Also, the proxy will not be able to get the server domain once ESNI is used, which means that the client already needs to resolve the domain name to the servers IP address which is a problem in restrictive environments where no outside DNS is available inside.

Apart from that, an explicit proxy allows for proxy authentication with credentials. With an implicit transparent proxy authentication can only be done by source IP, i.e. there need to be some previously established association between source IP and username which is not possible in environments where multiple users come from the same source IP (like with windows terminal server or other thin clients).


I feel that anyone interested in pursuing a security centric career should become CISSP early in the process.  If you are interested in remaining focused on development and wish to demonstrate security expertise, there are several other certifications that would be more appropriate.  I strongly recommend the SANS classes and corresponding GIAC certifications as they are probably the most technically insightful and demanding.  A specialist with one or more of the GIAC certifications is typically a very knowledgeable professional.

I would say that 12 years of experience and your use of the term "solutions architecture" suggests you are a senior practitioner.  I would therefore urge you to consider becoming a Certified Secure Software Lifecycle Professional (CSSLP).  This is a rather rare certification and can be a strong attractant in a high-end job search.  CSSLPs with a few other, related certifications are rare and can expect excellent compensation in the current job market where senior security personnel are in very high demand.

Not meaning to brag, but I speak from experience as I have 10+ years tenure as CISSP, hold the CSSLP, CISA and have a variety of other certs.  I am approached about a job opening more than once a week, though I am not looking.


What happens when authenticating through a phishing attack with FIDO U2F tokens

I ended up asking Yubico about this through twitter. The authentication currently just fails, but a manufacture could add a screen to a key that would give a more helpful notification.

The default user behavior will be to try again and then circumvent the security key through a one time password, which does allow man in the middle attacks.  So an important side note will be to teach users to not ever use the one time password option.


CURLOPT_SSL_VERIFYPEER and potential security issues

Yes, there are security implications. You've completely turned off certificate validation, you'll accept invalid certs. You've opened yourself to MitM attacks, and you might as well transmit over http, because you dropped all the security goodies of https.

You should look into why your server doesn't accept let's encrypt certificates (I'm assuming that's why you turned off the verification) and what you can do about it. Alternatively you can look into getting a cert from another CA.


Throttling failed login attempts: exponential timeout? by IP? using a session cookie? captcha?

I once considered using approach similar to Merkle's Puzzles. For example you could require every login attempt to be signed with HMAC using one time key. For example server could prepare puzzle in following way:
- seed (long random value),
- r (random integer value within some arbitrary range),
- key = PBKDF2(seed, r)

Than server could send following puzzle to the client: (seed, hash(key)). In order to get valid key, client would have to brute force this puzzle (check sequentially r values, compute PBKDF2 for given seed, compare its hash to hash(key) received from server). When client finds correct key, it uses it to sign one login attempt.

In this approach amount of work is asymmetrical between client and server (client has to do more calculations). Moreover, server can adjust the "work factor" changing the range from witch r value is selected.

Of course this scheme would not prevent password brute forcing, but it would increase cost of such an attack.

As I said it is only rough idea, I'm not sure how good it would work in practice.


How to secure consumer info without buy an certificate?

I need to know how to properly secure my consumers credit card info
  without buying expensive certificates?

RapidSSL certificates are as cheap as $49/year. Furthermore, properly securing credit card information requires a lot more than just using TLS and having a CA signed certificate.

If $49/year is a lot of money to you then I don't think you have the resources to properly store credit card data in a secure and compliant way. Presumably you are using free or very cheap web hosting which means you probably have a shared hosting environment with limited control over your firewall, logging, and other potentially malicious users on the system.

Having such limited resources does not mean you can't accept credit card payments, just don't host the checkout or store credit card details yourself. Check with your bank to see if they have a hosted gateway product, or look at something like Stripe Checkout or PayPal express checkout.

These will allow you to accept credit card payments without needing to use TLS (although I still recommend that you do), because your system will never come in contact with credit card data.


PCI DSS compliance on shopify using the client's payment processor

You may still have some way to go I'm afraid.

If the card data touches your server, then your server is in scope.

If your server not segmented from the rest of the network then your whole network is in scope. This could include physical access to buildings and every desktop in the company.

You can get an audit if you want to be super sure you are compliant but that is usually only done by people selling solutions.

It's a bit late in the day, but if shopify doesn't support this gateway then you should probably try to find a 3rd party that does. The major selling point of this sort of provider is that they handle the PCI compliance for you. If not prepare for headaches.


What's the difference between an API gateway and XML gateway?

A bit of an artificial distinction in my view. I am guessing that they are considering XML gateways to be document-based whereas they are considering API gateways to be record based. But this really is a guess because I would certainly not have a distinction between them.

An API is simply a documented mechanism for obtaining information via a service. What the API returns is part of the definition. API's might return JSON or XML or some other format, it makes no difference architecturally.

The point about DLP is also incorrect in that there is no reason why DLP shouldn't be applied to any API. However, in practice, DLP is mainly applied to documents (e.g. un- or semi-structured data). It doesn't have to be that way though.

Sorry, I realise that this does not exactly answer your question but hopefully, it at least adds some clarity.


password requirements vs password storage options

If the 'change password' form asks for the current (old) as well as the new password (as it should), it doesn't have to keep a plaintext copy around.

It can check that the old password is correct by comparing the hashed versions, and then do the check against the requirement you mentioned and only if it passes, update the password in the database.

(Update - changed "encrypted" to "hashed" to avoid distracting discussion on whether encryption is by definition reversible)


Respectfully disagree that policy discussions are offtopic for Information Security. Good information security starts with good information security policies.

IIS is a prohibited install on workstations under USGCB. This would suggest that any waiver must be based on a business case and approved by your agency's Designated Approval Authority as part of the Authority to Operate for your Major Application or General Support System.

Refer to your agency's security policy documentation and the NIST website.


Nessus Plugin "HTTP Smuggling Detection" failing due to support for http/1.1 - how to overcome?

According to here, this issue will show up if you have paranoia enabled. Did you purposefully enable paranoid scans?
Paranoid scans turn up with a lot of weird plugins like these. Another example of paranoia false positives I have seen was something along the lines of "Port 4444 is open, therefore there is a backdoor on this machine," which isn't necessarily true.
If you do need paranoia set to On, next, you then need to verify the validity of this plugin. In that case, I would recommend using Burp Suite (community edition is fine) and then running the HTTP Smuggler addon against your "vulnerable" host. It will do a much more thorough test on it than Nessus will.
Should you discover that your host IS vulnerable, then you should investigate patching your application. Generally speaking, this is not an issue with your code -- it is almost always a vendor patch for a web server or web appliance. Note that, due to how HTTP Request Smuggling works, you also may need to investigate and patch all other infrastructure which is attached to that application. Namely, that would probably be a load balancer or some type of middleware.


Eve could sign a certificate stating "a.com" as name, with her private key, but Bob's browser will not accept it. When Bob's browser validates a certificate chain, it verifies all signatures, but not only the signature. The complete validation algorithm is intricate; see the standard. In this case, Bob's browser will raise a metaphorical eyebrow when applying check (k) from section 6.1.4: Eve's certificate is a "version 3" certificate, but does not contain a Basic Constraints extension, or its Basic Constraints extension has the cA flag set to FALSE.

In short words, though certification is a kind of power delegation, the power to issue certificates is specified to require explicit delegation, and is not done by default. As @Terry says, commercial CA can grant sub-CA certificates, with the cA flag set to TRUE, but they will charge a lot for that. In fact, they will contractually bind the sub-CA to honour the Certification Practice Statement of the CA (see there for the CPS of Verisign). The contractual obligations include a lot of big money talks with insurances and things like that, so that a sub-CA Eve who would issue fake certificates would be blasted into oblivion by the legal retaliation from Verisign. They make no prisoner.

Things used not to work that way in the past. The first version of X.509 did not support extensions, so clients had to find some other way to verify whether a given entity had the CA power or not. This was inconvenient, because browsers had to choose between embedding a growing list of "allowed sub-CA", or simply trust all certificates with CA power (thus allowing your attack). Note that up to year 2003 or so, there was a bug in Internet Explorer: IE did not check the Basic Constraints extension at all ! When this was discovered, it was promptly patched, of course...


Why do HTTPS requests include the host name in clear text?

The hostname is included in the initial SSL handshake to support servers which have multiple host names (with different certificates) on the same IP address (SNI: Server Name Indication). This is similar to the Host-header in plain HTTP requests. The name is included in the first message from the client (ClientHello), that is before any identification and key exchange is done,  so that the server can offer the correct certificate for identification.

While encrypting the hostname would be nice, the question would be which key to use for encryption. The key exchange comes only after identification of the site by certificate, because otherwise you might exchange keys with a man-in-the-middle. But identification with certificates already needs the hostname so that the server can offer the matching certificate. So the encryption of the hostname would need to be done with a key either based on some other kind of identification or in a way not safe against man-in-the-middle.

There could be ways to protect the hostname in the SSL handshake, but at the cost of additional overhead in handshake and infrastructure. There are ongoing discussion if and how to include encrypted SNI into TLS 1.3. I suggest you have a look at this presentation and the IETF TLS mailing list.

Apart from that, leakage of the hostname can also occur by other means, like the preceding DNS lookup for the name. And of course the certificate sent in the servers response is not encrypted too (same problem, no key yet) and thus one can extract the requested target from the servers response.

There are a lots of sites out there which will not work without SNI, like all of Cloudflares free SSL offer. If accessed by a client not supporting SNI (like IE8 on Windows XP) this will result in either the wrong certificate served or some SSL handshake error like 'unknown_name'.


What is the current best practice to secure an executive's laptop?

The biggest thing you can do is user training.  The majority of targeted compromises are a result of stupid users.  It doesn't matter how secure you can make the system when your PHB (pointy haired bastard) follows the link spoofed from their buddies e-mail address to some custom malware infested porn site and clicks ok to every dialog they see.

If you can't get awareness of security and what are appropriate uses of the computer and get the executive's buy in on that, then no amount of additional effort on your part will make a bit of difference.  If you can get their buy in and investment in keeping the system secure, then most of what you described is fine.

Another alternative is to give it an always on internet connection and use it like a dumb terminal for a virtual machine hosted within the company's network.  That's a bit more pricey and a bit more of a nuisance, but it is even more secure as you don't have to worry about whether the laptop may be able to be hacked if lost because there won't be anything on the laptop itself worth stealing.


Dealing with expired or revoked signing certificates with Infopath documents

I don't know how Infopath works but your question is a general issue in the long term digital signature validation field.

The solution is to store along with the signature all information required to validate the signature (e.g. all certificate paths, downloaded CRL or OCSP responses...) and to wrap everything with a cryptographic time-stamp (as defined in RFC 3161). This time-stamp provides a proof of existence of all theses objects at the time-stamp date. Therefore it is possible to replay the signature validation process in the past (i.e. when the signing certificate was valid/not expired)

I've found this link http://msdn.microsoft.com/en-us/library/cc545900.aspx about digital signature in MS Office 2010 and it seems relevant for Infopath. You need a XAdES-X or XAdES-XL signature level, depending on how far in the future the signature should be validated.

Hope this helps.


Reverse shell on a web server behind Netscaler

Assuming that the Netscaler (or other load balancing appliance) is configured properly and the network architecture is such that the target server cannot bypass the load balancing layer to directly reach the internet, you cannot expect to get a normal reverse shell to work.

There are a few ways you can approach this problem:

If the Netscaler appliance is configured to allow SSH forwarding for remote management purposes, then you may be able to have the payload add a user.
Have the payload drop a webshell onto the system which allows for interactive access to be tunneled through the load balancing layer.
Exploit the vulnerability repeatedly and have the payload tunnel data back through an out-of-band channel, e.g. DNS requests to subdomains of a system where you control the nameserver.
Attempt to attack the Netscaler itself. There's an old Netscaler management application written in Java which uses a custom protocol on top of TLS, but the protocol is fairly trivial and there's no account lockout, so bruteforce is trivial. The server always has the management port open on the internal side and (last I checked) there's no way to disable it.


Hashing cookie-values & preventing cookie-stealing

To simplify your question:

You want to share some secret (i.e. hashed cookie or whatever) with the user.
You don't what to have any user involvement in protecting the secret, i.e. no login or whatever.
You want this to be save even if the computer was hacked.

This is impossible. If the computer is hacked the attacker can do everything which does not require any specific user interaction (like entering password only known to the user). This means that the attacker is able to access this secret and can use it. You might add some information about the computer into the secret (i.e. source IP, browser fingerprint...) so that it is hard to use the secret from another computer, but the attacker can still use the secret directly on the victims system.


Is there any security reason for re-directing to the main/mobile page after login?

This practice of resuming the original request after authentication is sometimes called "bookmarking," because it allows users to bookmark specific parts of a site and "go there" by way of the login process.

When bookmarking isn't available, it's usually a sign that the site wasn't designed or architected to allow it.  For example, if authentication is detected and enforced by a border device (like a Web Application Firewall), then the redirection to the login page may take place there, leaving the back-end application without any indication of what the initial target was.

In this case it would be a security-related decision - it is the imposition of the WAF that restricts the choices of the application.  Similar limitations can also occur solely within the application, if it isn't designed to maintain that state through the login process, in which case it wouldn't be a security-related limitation.


Do Social Network Mobile Apps Track Your Browsing?

Absolutely. Apps employ ad networks which are shared among different websites that share the same ad network (AdClick as an example). The ad network installs cookie on the system which gets shared between websites you visit and share the same ad network. That is, your unique cookie gets tossed around, which helps track your movement across the web.


What are some possible uses of a zip bomb?

Most antivirus are able to detect zip bombs. In this modern day. Zip bombs doesn't cause much effect or not at all to systems.

Antivirus scans 3 downlevel usually unless you changed the settings so

Zip bombs don't cause AV to crash therefore does not "create" a scenario where AV crashed and opportunity arises for malware to infect the system.

System Processes now work more efficiently as compared to earlier days when zip bombs are reigning.

If unpacking zip bombs consumes memory. It pretty much are contained within the process. The process handling the extraction would just run out of memory and crash.

Writing a script and slowly extracting the zip bombs does not make a dent in the system, running out of space, the unzipping would fail.

Again modern day systems running into low disk space will sound a 'low disk space's warning. All the user needs to do is find large files and just deleting them.

Even if disk spaces are full, system will still run at minimal mode.

Zip bombs are not what its name says it is. When you unzip a zip bomb, it doesn't "explode" in a grand fashion. If you use the extract all function. It's just gonna crash. Period.

So what about possible use case?
I probably say use it to troll someone, wasting 10secs of their life? But then again you be wasting your time and effort creating it.

In my opinion it isn't worth doing it now.


Firewall Migration: NetScreen NS500 to FortiGate

If I were you, I'd try posting in the Juniper forums and the Fortinet forums.

When you running old, unsupported versions, the vendor usually doesn't want to know, especially when you're moving from them. However, if you have a support contract with Fortinet (sorry I'm not familiar with them much), I'd have thought that your Account Manager would've been helpful?

Regarding general firewall migrations, 9 times out of 10, I found manual to be better, although more tedious. When the upgrade was version upgrade within the same product line, it was much easier and straight-forward with the latest version/package from the vendor. Otherwise it was more painful and required copying each rule over (taking notes for the 5-tuple and any other information).

Good luck!


It would be as secure as the phone and the token transfer is. I.e. if the user looses the phone or if the phone gets compromised by malware or if the user displays incoming messages on the lock screen so that others can see it too or if someone can capture the SMS (or whatever you use to send) then the you've lost.
Insofar it is similar to sending the token per email and hoping that only the user has access to the account and that nobody can sniff the transport of the mail.


Basic questions about a buffer overflow attack example

In order for a buffer overflow to occur, you would need to have a buffer that an attacker can input data into while exceeding the intended size of the buffer. The example code you shared does not contain a buffer overflow, but rather a memory leak/information disclosure vulnerability. When running the program, it will print out contents of the stack beyond your array, or potentially crash if it reads completely past the stack's memory region. Without any other functionality in the program, there is nothing to exploit; such a leak may be useful for defeating exploit mitigations but it is no good on its own.
The actual code segment that is loaded into memory is generally read-only, so most attacks do not involve trying to change it. Instead, attacks will redirect program execution to memory the attacker can write to, or reuse legitimate parts of the code to perform arbitrary actions.


What is the best way to track the authenticated user on the server side?

In ASP.NET you can keep the session in a data store instead of in memory, this is useful for load balanced deployments. The session can be kept in SQL and I have also found an example of using Redis to store it so retrieval is faster.

So in your case I would use ASP.NET authentication and then use the session to keep the primary key you mentioned in order to recognize the user.


Which is more secure: develop a mobile app in its Native language or using cross-platform UI?

There are two main things to watch out for:

you will make fewer mistakes in the environment with which you're more accustomed. If you understand secure coding in, e.g. C# better than Objective-C, then Monotouch might be better for you than Cocoa Touch.
the combination "your code + operating system" has a smaller attack surface than "your code + third party library + operating system".

In almost all cases, the contribution from the first factor is far greater than that from the second.


Computer identity still recognised after reinstall

Because of the MAC address.

The MAC address is stored on your internet card and is shared with the router to route the internet packets. Since, you connected with the cafe wifi, it gave your MAC address to the cafe router which they then used to identify your computer using the information they previously stored.


Alternative to Proxy servers for limiting internet access?

There are several ways to secure and restrict internet access to mobile workers. One major idea is to filter at the DNS level, i.e. block name resolution for harmful domains. For example there are products from Cisco and Cloudflare in this area, probably others too. Since this is only filtering the DNS access these solutions are very lightweight. But on the other hand they cannot do any actual content inspection, like scanning the traffic for malware.
Such content inspection can be achieved by a proxy though and this is what you currently use. But instead of having a single proxy installation central in the company with all the overhead and scalability issues you experience, it might be better to have a proxy nearby to the mobile worker.
Nearby can mean on the endpoint itself, usually as part of some centrally managed endpoint protection or antivirus suite. Nearby can also mean in the cloud though. Several classic firewall vendors let you for example install their products in the cloud, but there are also cloud-native managed security solutions from ZScaler, Cloudflare and others.


I see no form of authentication to make use of it

I think in this case you have to wrap the process yourself. stunnel is an application that allows you to wrap any TCP connection with SSL and permits mutual authentication where both the client and server are validated.

You would run stunnel to forward connections to the localhost only listening service on the Unity server. Your developers would run stunnel clients to connect to your server and provide a port on the local machine and then connect to the Unity cache on the local machine port, thus forwarding all communication over an authenticated and encrypted channel.


OpenVPN Key Size 1024 vs 2048 and Eavesdrop vs Access?

There's a few misconceptions in your question - I'll try to help:

OpenVPN recommends using a 2048 RSA key size for greater security, however, the hardware I'm using is somewhat weak and defaults to using a 1024 RSA key size.

Larger RSA key sizes give you better security specifically at authentication and key exchange. And your hardware needs to be very weak not to handle 2048 bit keys. (I will try to find actual data around this, though I'd suggest an old Pentium II would handle an RSA 2048 within reasonable time.)
So my guess is that your hardware will handle RSA/2048 bits just fine.

I'm trying to determine if it's worth the hassle of manually changing things to a 2048 sized key. I'm not concerned about anyone eavesdropping on any data being send over the VPN connection ...

So you don't need a VPN?

I am concerned about someone opening a VPN connection themselves that isn't authorized to do so.

This is a reasonable concern, though not something that relates to your RSA key size directly. Or not at this level. It's far far easier to attack an existing client than to brute force even a relatively short RSA key.


Why am I allowed to access protected Windows files when I boot Ubuntu from USB?

The file and folder/directory permissions on an operating system are managed and enforced by... you guessed it right, that operating system (OS). When the operating system is taken out of the picture (booting a different operating system), then those permissions become meaningless.

One way to think of it: You hire a big bodyguard (OS) to protect your house. You give him a list (permissions) of the allowed guests (users) and which areas (files and folders) they're allowed to visit. How useful are those lists when the bodyguard is asleep (not booting from that OS)?

Generally, it is assumed that once an attacker has physical access to your system, they own your system. Even a BIOS password won't help you in this case. One way to solve this problem is using full-disk encryption using software such as TrueCrypt, Bitlocker, and others.

The problem, in your case, is that you'll have to setup a password (or key) to be inputted whenever you reboot the system. Weigh in your options and decide.


WSS (WSS4J): cleartext password in UsernameToken vs salted password hash in database

Thanks to Ivan Brencsics from the CXF mailing list for providing this hint. He writes:

If I understand correctly your question, your problem is that you dont [can't]
access the password in the CallbackHandler, so you cannot hash it and
compare it with the database.

I ran into the same problem recently, and I solved it by registering an
org.apache.ws.security.validate.Validator instead of a CallbackHandler.

So for instance:

<jaxws:endpoint ...>
  <jaxws:properties>
    <entry key="ws-security.ut.validator" value-ref="sqlTokenValidator"/>
  </jaxws:properties>
</jaxws:endpoint>
...
<bean id="sqlTokenValidator" class="org.my.SqlTokenValidator"/>

and finally SqlTokenValidator:

public class SqlTokenValidator implements org.apache.ws.security.validate.Validator {

@Override
public Credential validate(Credential credential, RequestData data)
throws WSSecurityException {
    ...
    UsernameToken usernameToken = credential.getUsernametoken();

    String username = usernameToken.getName();
    String password = usernameToken.getPassword();

   ... hash the password
   ... sql_auth(username, hash password)
   ... if failed throw new WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION);

    return credential;
}

Oh and thanks to Polynomial for suggesting I check out the CXF mailing list.
Still don't quite see the appeal of mailing lists over a proper forum ;)


Security review: is this PHP mcrypt wrapper class safe?

No, this is not secure.

The HMAC check is vulnerable to timing attacks. Since the author uses a standard string comparison, the check stops as soon as one character from the provided HMAC doesn't match the corresponding character from the expected HMAC. So the longer the common prefix, the longer the check takes. By carefully observing those time differences, an attacker may be able to reconstruct the expected HMAC and “forge” arbitrary data. This is a well-known error.
The length parameter of strlen() and substr() refers to characters rather than bytes in some PHP setups, which will break critical functionalities of the library. For example, the popular “mbstring” extension provides encoding-aware implementations of strlen() and substr(). In this case, multiple bytes may be counted as a single multi-byte character.
Encryption together with compression is known to be problematic in certain scenarios (see the CRIME and BREACH attack against SSL/TLS). The compression feature is turned off by default, though.
The cipher configuration is arcane. For example, the desired length of the PBKDF2 output is specified indirectly through the PBKDF2_BLOCK_COUNT constant which is the minimum multiple of the hash function output required for the target length. This creates a huge risk of user mistakes, especially when the library is marketed as an easy alternative to Mcrypt.
The author confuses the block size of AES with its various key sizes. MCRYPT_RIJNDAEL_128 is not AES-128. The numbers of the MCRYPT_RIJNDAEL_* constants refer to the block size of the Rijndael algorithm, whereas the numbers of the AES variants refer to different key lengths. AES is Rijndael with a block size of 128 bits and a key size of 128 bits, 192 bits or 256 bits. So to get AES in PHP, you use MCRYPT_RIJNDAEL_128 and a key string with either 16, 24 or 32 bytes. The library uses a 32-byte key by default, which means it employs AES-256, not AES-128.
The key derivation looks rather odd: Both the encryption key and the HMAC key are based on the same output of the PBKDF2 function. The only reason why they're different is because the literal strings "EncryptionKey" and "AuthenticationKey" are mixed into the HKDF call. This isn't necessarily wrong. In fact, the RFC specifically supports an extra input parameter. But it might be safer and more robust to generate enough key material for both applications and then split it.

The main problem, however, is that the library relies heavily on home-grown implementations when it should use standard solutions. For example, combining encryption and authentication should be done with AES-GCM. The PHP OpenSSL extension also provides a complete PBKDF2 implementation.


What personal data should be encrypted in a database?

There is no definitive list of PII that should be encrypted.
Encryption is a security control that mitigates risk. There are many other controls than can achieve the same result.
So, you need to perform a risk assessment to determine what stakeholders require, what regulatory/legal obligations you have and what risks you face that could be mitigated with encryption.
Encryption is often a Good Idea™, but regulations tend not to specify it because encryption is not a "tick the box" exercise and the regulations don't want to get into the technical details of how to do it correctly. They just specify an outcome they expect.
So, to answer your question, the data that should be encrypted is the data that you have determined should be encrypted.


PHPMyAdmin vs Remote client restricted by IP address

Sequel Pro offers some interesting connection methods that you just don't have with PHPMyAdmin.

With Sequel Pro you can connect to your MySQL Server via SSH. This means you can take advantage of the private/public keypair connection of your OS (that's heaps better than passwords).

private/public keypair is a better login option than passwords (so using SSH via Sequel Pro would be more secure than using passwords with PHPMyAdmin).

If you do want to use PHPMyAdmin you should consider these points:

Consider using HTTP Basic Auth in front of PHPMyAdmin
Always restrict access to only your IP Address if you can (this can help cut down on a number of login attempts)
PHPMyAdmin needs to be secured, and kept up to date
don't have predictable file locations such as /PHPMyAdmin (this cuts down on the attempts from automated scanners)
Make sure you use HTTPS
PHPMyAdmin configuration can store credentials, these could be compromised


This is speculation, of course, but they may have implemented their original system before security was at the front of everyone's minds.

Once you've implemented a system like that, you tend to reuse it in many places, and so you build up a lot of dependencies on it. And once you have dependencies, making changes becomes very expensive. Even if they had knowledgable people telling them it was insecure, and they need to change it, the cost would likely have been higher than the perceived risk.

Until the risk is realized. Then they learned the hard way that they need to take such things very seriously.


Bank Has Emailed My Social Security Number

There is a way to safely encrypt email, but you would know (without looking at the headers) since there must be a way for you to authenticate yourself as the receiver.  If they put a signature cert on the email, that does not mean that it is encrypted, that only provides a way for you to confirm the identity of the sender.  The encryption must be performed in addition, usually in the form of an add-on to your email client or a server to server encryption in a business environment.  If there were any health questions in there, you could be looking at a HIPAA violation.  You should question the security practices of an entity if this is a normal practice.


If you don't know the key, you can't generate the HMAC. That's the whole point of a HMAC - it's a quick way to provide message integrity using existing key material. If you could regenerate the HMAC without the key, an attacker could simply generate a HMAC for a different message and alter the payload.


What is required to decrypt other device's WPA2 packets?

Lets say packets between Device B and the router are captured on Device A through Wireshark's monitor mode. Just making sure, but does Device A have to be already connected to the network to capture these packets? (I believe the answer is no?)

The answer is, indeed, no.  In monitor mode, you have a radio receiver and hardware that turns the radio signals into 802.11 packet headers and payload and supplies them to the host, regardless of whether you're associated with the network.  Obviously, you have to be "connected to the network" in the sense of the radio receiving on the channel that the network is using.

  As far as my searching and understanding, at minimum you need to have the preshared key/wireless password as well as have captured the EAPOL packets between the router and Device B to decrypt the packets from the scenario above. Is this correct, or is more/less needed?

That's correct (for WPA/WPA2 personal).  See the Wireshark Wiki's "how to decrypt 802.11" page for more details.


Using primary public-key to verify message signed by subkey

You have to provide the public subkey to the recipient in order for them to validate anything signed with the corresponding private subkey.

The Master key serves a purpose somewhat analogous to a Certificate Authority.  It represents your authority to bless all your personal subkeys as valid keys that were issued by you.  But just as having a root certificate doesn't mean you can use TLS to talk to any random server that was issued a public key - you still need that server's public key (which is delivered on the certificate.)


Is it safe to store user's secure pass-code in database with encrypted form while creating bitcoin wallet?

1) No. If you have a way to bypass the user's password, then you have a way in their wallet. Thus, if a user forget his password, they lose access to their money (and any attacker too). That's the point of a password.

2) Yes. That is more likely than you might think.

The best practice is for users to use an offline wallet that do not upload their data to a server.

Also, do not forget to backup (and test the backups) the server's data, because that's also your users' money that you have to reimburse in case of hardware failure or natural disaster. Before you start to develop this system (software and hardware), you must do a (security) risk assessment and discuss with your insurer. Do it again before releasing your service. There might also be legal obligations related to handling money and users' sensitive information, depending on where you live and to whom to will provide this service.

Take care not to roll your own cryptography. Depending on what you mean by “pass-code”, this scheme can be inherently insecure.


Not hashing email registration confirmation link

The only issue is that you're leaking information, in this case, the user's email address.  Since it's plaintext in the querystring, it's going to be stored by any logging that's occurring anywhere between the client and your server, potentially in bookmarks if the user bookmarks that page, if the URL is copied and stored or sent to anyone, etc.

I'll additionally point out that anything you do is going to be vulnerable to sniffing, since you're using HTTP rather than HTTPS.


Do not try to turn the tables.

Simply disconnect the site from the internet, take forensic copies (if you want to try and find out exactly what happened, or pass into to law enforcement) and then wipe and rebuild from scratch.

As the odds of tracking down the perpetrators are incredibly slim, I would suggest not wasting your money. Just wipe and rebuild, and look to garden your installation before you connect it online again. This should include latest patches for platform, OS, applications etc., config options and general hardening guidance.


what kind of signature to require in a medical B2C environment

I assume now that you are talking about document the customer signs and sends to you, like a order or request for medical service:

Most solutions I have seen in this case, involves external signing. Ergo, you don't sign using PDF signing functions, but instead, sign the whole file as an opaque data object.
The reason is that PDF signing either requires a valid CA, or a imported "home-brew CA" for the PDF reader to see the signature as genuine.

Here in sweden, when doing medical services, you fill out the PDF form (or web form or whatever), and then upload it to the medical service. Then you use a electronic ID, here in sweden its called "Mobilt BankID" (Mobile ID app) but I really don't know what you use in your country, to sign it.

And when signing it, you basically take the hash of the file (SHA-1), and send to the electronic signing service. For example:
"Signing file form_2016-11-11_00:05.pdf with SHA1 validation value 5C:1C:2D...(rest of SHA-1 hash)"

Then you effectively save the signature you get from the electronic ID service, along with the PDF.
If any doubts of tampering appears, you can show that the received PDF file's hash matches the hash inside the electronic ID signature message, and the signature of the message matches the actual signature.

Note that you cannot tamper with the PDF file, like adding notes and such. If you need to add content to the PDF, you have to copy the PDF to a new file, that you can add notes to.

Even if most users do not understand how to verify the hash matches the PDF when they get the on-screen message "to sign a file with hash XX:XX:XX....", it does not matter. Its enough that a few users do understand how to verify it to make tampering a too high detection risk for a attacker.

There must be some official solution (like some government electronic ID or something) intended for customer usage, that is OK to use according to HIPAA or DPA.

However, if you instead are about to sign documents that you are sending to the customer, its enough to purchase a certificate intended for document signing. Then you use PDF signing tools to sign the PDF.
The PDF can then be viewed on any computer, and if the PDF software supports digital signatures, the signature will be validated automatically. The customer does NOT need to install any custom software.


Is every packet in a home Wi-Fi which has say, AES password for connection, encrypted using the same password?

According to Kerckhoffs's principle, secrecy depend on key not in encryption algorithm. Therefore Knowing encryption algorithm does not help to decrypt traffic. But implementation is critical. WEP is very weak, It is possible to break less than minute, because of poor implementation.
If your link is properly encrypted with secured algorithm such as WAP2+CCMP It will be very difficult to read captured traffic.
AES is used by CCMP and it will be secured environment. If your connection is encrypted it is not possible to read traffic goes to http traffic. Because your entire data packet is encrypted in secured connections including header.
If they know the password yes they can sniff and read content but it should be done before login.
Always keep in mind, no system is 100% secured. Be Sure what you are doing?


How were weak passwords brute forced in github?

Given that bcrypt generates a random salt per password and that the Github database wasn't compromised, how was a "remote" brute force attack possible and how long* was that process?

Two different attacks are being confused here.  Brute forcing password hashes means the attacker has got ahold of the database table containing the password hashes and if they are properly salted and hashed, then it is very time-consuming to brute force.

In this case, github was attacked by guessing passwords at the login page so it doesn't matter how the passwords are salted or hashed or anything.  It just matters if the user in question used an easy password.  Github says "we aggressively rate-limit login attempts" which means it locks an account out after x tries for a certain amount of time.  The attacker had resources (40,000 unique IPs to guess from) many accounts to choose from, and a long period of time so they could lazily keep guessing and waiting for the lockout to expire.  Even with all those resources, their bot can't guess fast enough to break into accounts with anything but dead simple passwords.

It is really great that github posts a security history at https://github.com/settings/security for your account to see account activity (failed logins, logins, etc.)


Setting up SFTP at Production Server is a Risk?

Anywhere you provide the facility to upload content, there is a risk of uploading malware. Either manage the risk or don't allow uploads.

Regarding the protocol, unlike HTTP(S) and SMTP servers, I'm not aware of any SFTP server which allows you to deal with the files as a synchronous operation triggered by the upload. However it is possible to do it asynchronously on Linux with minimal latency using inotify (but there are some complications over handling transfers that take a while to complete). You can also poll the directories or monitor the SFTP log to trigger processing on the gateway.

Regardless of the method you use, you should keep uploads and downloads separate, and keep each users uploads separate. And not make content available as a download until you've checked its content.

As to the processing required to deem that a file is safe....using an anti-virus product is one solution, however:

they are only effective against known exploits
most configure themselves to run on-access. This is nightmare for a gateway type scenario where you want to control the dataflow programmatically
the ones that can be configured to scan on-demand frequently do so as a single process - i.e. the program needs to load the entire virus definition file for each operation, uses a lot of memory, disk I/O and time

(a notable exception to 2 and 3 is clamdscan which acts as a frontend to a scanning daemon).


Using PGP to encrypt emailed password reset token

Keep it simple. Sending signed mails with given, parseable format makes things rather complicated. If a user opts for encrypted mail, send him (all, including all other) mail encrypted, including password resets.

Selbstauskunft.net (German language only), a service for sending requests to companies request information they store about you based on privacy law, lets you do exactly this: you can select an OpenPGP key (which they list based on a keyserver query), and if you do so, they will also encrypt the password reset mail.

Regarding OpenPGP mail interfaces, only Hetzner, a German hosting company offering an e-mail API using OpenPGP signed message for domain registration.


How can I verify my browser/OS's top level certificate?

In most browsers, you should be able to view the certificate for a site, and follow the chain up to the root certificate.  For example, in Firefox for security.stackexchange.com, you can follow the following steps, and see that the root certificate of the chain is DST Root X3.

1)  Navigate to security.stackexchange.com, and click the green padlock in the address bar
2)  Click the right arrow, next to 'Secure Connection'.
3)  Click 'More information'
4)  Click 'View Certificate'
5)  Click 'Details'

Then, look at the certificate hierarchy.  You should see the following chain:

DST Root CA X3
  + Let's Encrypt Authority X3
    + *.stackexchange.com


Tor "Security Slider" - What security does it provide?

The Security Slider allows you to choose compromise between security and convenience.

At normal, convenience is first. All features are enabled.

At safer, javascript over HTTP is disabled. This is important as without using HTTPS, an attacker (for example an exit node) could inject malicious javascript. Also, video and audio playback often has security problems, plus ads use it to be annoying, so it is disabled. I am not sure why symbols are disabled, but I suspect there may be either rendering problems (symbol going beyond the space it is supposed to be in) or crashes similar to all those UTF character freezes and crashes on mobile phones.

At safest, all javascript is disabled by default. This will in addition to preventing MITM injection also prevents XSS attacks and intentional attacks by the sites you visit.


What is this scheme called and how should it work exactly?

The specific phrase you're looking for is "key exchange".
https://en.wikipedia.org/wiki/Key_exchange

There are a few schemes(many deprecated) for accomplishing this securely, but if you're writing your own program(and thus aren't as worried about "who is this person actually", and just about securely exchanging the keys), Diffie-Helman is a good place to start at.
https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

Diffie-Helman is specifically designed to make exchanging keys secure even if observed. If you are wanting to make key exchange secure against MitM attacks, that is where having certs signed by a trusted CA comes in. A trusted CA will not(or is not supposed to) sign the same identity for multiple parties, so an attacker in the middle intercepting the legitimate public key before it is given to the intended converser will not be able to sub in their own public key, since it won't be properly digitally signed.

Nonces are indeed there in order to make sure each message is only being replied to once, and usually within a set time. They don't prevent an attacker from intercepting them, forwarding them on, intercepting the reply, forwarding that, etc.
Forward Secrecy is considered the best practice now.
https://en.wikipedia.org/wiki/Forward_secrecy
With systems implementing forward secrecy, new keys are generated each session, so that previous session information cannot be compromised using a mitm interception of the new keys. Note: you're not generating new long-term private keys each session, you're generating new and random 'secret keys' (i.e. the key used only during that session to encrypt traffic).
The user-specific private keys which are used to generate per-session secure keys are kept, but those keys are not the keys being used to directly encrypt and decrypt traffic.
Apart from private key compromise, nothing can prevent a mitm from tampering with traffic they can touch. Proper CA signatures can prevent the certificate chain from being valid if they do tamper with something, but that won't actually protect the data; just its trustworthiness.


SMS: Apple has detected multiple failed login attempts

This could be sent from a hacked phone server, hacked phone account for sending sms, or from a service that has unlimited sms.

Is this the literal message? Is this all that was in the message? If I google for this (with quotes) I don't get a result back.

Do you see a number or name? Google it and post it here.


A similar thread was discussed a couple of days ago. Hope it's of help for you. If not let me know. https://superuser.com/questions/1213475/console-window-keeps-popping-up


SSL Pinning: Managing changes in the pinned certification on client side

You can pin more than one certificate, and you should pin at least 2. If somehow you lose access to one certificate, you can use the second. With only one certificate, nobody that connected to your site with pinning enabled will be able to connect to your site via HTTPS until the certificate expire (but they can connect via HTTP). If you employed HSTS, nobody that ever connected will be able even via HTTP.

So, as long as you have a valid certificate, you can alter your webserver configuration to send the current and the new certificate on the same response, and the browsers will cache the new one too.

For example, your server uses the current setup:

Public-Key-Pins: max-age=2592000;
pin-sha256="abcd9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g=";

And the certificate with fingerprint abcd9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g= is to expire in 2 months. You just alter the server configuration to add the new certificate LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ= with the response headers:

Public-Key-Pins: max-age=2592000;
pin-sha256="abcd9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g=";
pin-sha256="LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=";

But if you let the certificate expire, you have to wait until the max-age expires to be able to send another certificate.


You should disable the VRFY and / or EXPN these commands can expose user information to people probing a system in preparation for an attack.


Looks like bending the rules
The IANA TLS extension registry says RFC6066 is the current defining document for the "server_name" extension.
And the RFC6066 section on SNI says:

Currently, the only server names supported are DNS hostnames; however, this does not imply any dependency of TLS on DNS, and other name types may be added in the future (by an RFC that updates this document).

There is no such RFC update. None is listed in the registry. (Also no such "updated by" is listed in the RFC's first page top left corner.)
And a bit further down, there's this:

TLS MAY treat provided server names as opaque data and pass the names and types to the application.

I read this to mean "whenever we invent a new type, we may do this but now with the current DNS hostnames, we won't".
So if somebody still puts just anything in there, then I'd say they're in a grey area/bending the rules.


What is the "openssh-blacklist" package? Is it related to the Debian OpenSSL bug?

Yes it is related to the Debian OpenSSL "bug". It contains a list of of all DSA-1024 and RSA-2048 keys generated by a Debian sabotaged OpenSSL PRNG.


Guaranteed Public Key Authenticity besides Physical Meeting and (Possibly Untrustworthy) Root CA's

The fundamental question you're wrestling with here is:

How do I know that the human at the other end of the internet is who they say they are?

As far as I know, there's only two ways to accomplish this:

Pre-share some information out-of-band, usually the hash of your public key, at a physical meeting, a phone call, printed on paper in a sealed envelope, etc.

If you have a common person that you have both already established trust in, then you can extend trust. Ex.: a mutual friend in PGP, or a common root CA in PKI.

If you want to reject both of these and conjure trust out of thin air, then you might be stuck, regardless of the technology you use.

On the note of technologies, let's talk about two:
Diffie-Hellman
DH is a method to establish a shared secret with someone at the other end of the wire in such a way that an attacker can't eavesdrop it. DH has no inhearent mechanism to authenticate that the person you're talking to is in fact who they claim to be. When authentication is required, DH is usually augmented by requiring each person to have a certificate issued by a commonly-trusted root CA.
Quantum Key Distribution
If cost is not a concern, then QKD might be your answer. Instead of sending information encoded in voltage, like we usually do, a ~$1 million USD QKD machine encodes information in the spin of quantum particles. By the laws of quantum physics, this means that any eavesdropping will alter the message and the receiver will know. Like Diffie-Hellman however, this is a way to secure information in transit ... it doesn't do much to prove which human is at the keyboard.


Smartphone app as a U2F hardware token via Bluetooth?

Definitely Less Secure

The two biggest concerns apply to all software tokens, not just FIDO.

Platform Vulnerabilities

Hardware security keys provide a relatively strong protection of their cryptographic secrets (either a private key or a seed value). This protection is severely reduced when you implement the functionality on a general purpose OS. If the OS is compromised, an attacker could steal the secret. This extends the risk to include firmware bugs, debug modes, OS vulnerabilities, other software, user issue, etc.

With the well-known problems keeping Android phones up to date, it is especially risky on that platform.

Exclusive Control

The second issue is that compromised credentials are apparent with a hardware token. A user probably will never notice when their smartphone is hacked. In all likelihood, the 2FA app will continue to function normally. With a hardware token, a user will definitely notice when their token is lost or stolen.

You can generally assume a user has exclusive control over their 2FA hardware until shortly before it is reported lost. There can be no such assumption for 2FA credentials stored in software.

Bad Security, But Possibly Worth The Trade-off

In the end, a software 2FA implementation is more prone to being compromised and less prone to detecting successful attacks.

However, it will be cheaper and easier to provision if your users already have supported devices.

This is a classic cost-vs-security trade-off, and organizations make decisions like this all the time. Personally, given the low cost of hardware tokens, I would never choose the app, even if it were free.


Why is application crash considered insecure?

It crashed because some input was not processed correctly. An attacker may try to find the code path that leads to the faulty procedure and attempt to execute arbitrary code through potential vulnerabilities.
Crashes may give an attacker valuable information about the system and its internal details.
Crashes may create temporary vulnerabilities or leave unprotected files (e.g. memory dumps) that may be exploited.
(Thanks and a hat tip go to Ladadadada) The application that crashes needs to be restarted, which obviously takes time (even with watchdogs and symmetric failover schemes). If an attacker replicates the conditions leading to the crash your service will suffer from prolonged outage (Denial-of-service) which means financial, reputation, and other losses.


How to manually detect and remove Linux.BackDoor.FakeFile.1 from linux system through the command line?

To detect the backdoor through the command line in user's home directory:

if [ -d "~/.gconf/apps/gnome-common/" ] ; then if [ `sha1sum ~/.gconf/apps/gnome-common/gnome-common | awk '{print $1}'` = 0138fc4d50c734e288388f7c8cbbea5e2ad08a8b ] ; then  echo "Linux.BackDoor.FakeFile.1 was found!"; else echo "You havn't virus"; fi else echo "You havn't virus"; fi

I think, this backdoor virus can't start automatically. User must run it from command line. Nautilus can't start it. But if you mount /home directory without exec privileges, you can live happy!


How fast can SHA-1 be brute forced when used with a secret?

It is possible to brute-force with 7 Giga SHA1 per second on a good system. When we assume that your "secret" is indeed randomly generated (as it looks like) and is 120 bits long, we can guess the necessary time to find a match:

  possibleCombinations = 2 ^ bitsOfPassword
  expectedTimeInSeconds = (possibleCombinations / triesPerSecond) / 2

This makes about 3E18 years, so brute-forcing is clearly out of question. As mentioned, this only applies for really random "secrets". If only the SHA1 hashes are stored in the database, there should be no way to guess the "key".

I wonder what your intention is although, there are better ways to combine a key with a token (HMAC), or is it used in the context of password storage?


The problem with deleting files is that the file data is just one small part of what really gets saved onto your disk. On a modern filesystem there will be lots of metadata and other artifacts scattered around the disk:

Journal entries on journaling filesystems, e.g. NTFS, ext3, ext4.
Search index entries.
Prefetch / superfetch cache entries.
Shadow copies.
Image thumbnail caches, e.g. WinXP's thumbs.db / Win7's thumbnail database.
Temporary files, e.g. from ZIP/RAR extraction.
Alternate data streams (ADS), e.g. EFS FEK descriptors.
COM / .NET object registration data.
Wear leveling sectors on SSDs / USB flash drives.

This presents a challenge. Simply deleting the file data securely will only result in that data being deleted. There's no guarantee that the metadata won't contain sensitive data, or even be enough to reconstruct the entire file or match its hash against that of a known plaintext.

For example, even if the file is deleted we might be able to detect the following:

The name of the file and when it was created / deleted / modified.
A cryptographic hash (or checksum, e.g. CRC32) of the file, from an indexing database.
Occurrence of certain words or phrases inside the file from a search content index.
Company name, product name, COM object interfaces, .NET namespaces, etc. if it was a PE executable.
A thumbnail if the file was an image.
Various metadata from latent alternate data streams.
Partial plaintext from temporary files and wear leveling sectors.
Entire plaintext recovery from shadow copies or temporary files.

Identifying the locations of these and appropriately deleting them is cumbersome and may not even be possible in some cases. The best you can do is manually go through and clear any backups, delete the files, clear out your caches, wipe your thumbnail database, then do a cipher /W pass to ensure that most of it is wiped. Unfortunately even this won't guarantee anything, since some of it is stored in files and structures that are just trimmed or modified instead of properly deleted, resulting in blocks of data that are unlinked from the structure but not wiped.

So how can we get round this? The only real way to do it is with full disk encryption. Use an industry standard like TrueCrypt to encrypt your entire hard disk, using a strong password. Even this isn't 100% foolproof on SSDs with wear-leveling (in which case TRIM and Secure Erase are good options) but it protects you against all relevant practical attacks as long as you're not worried about governments throwing a ludicrous budget at recovering your data.

Of course, if you're really paranoid, the only guaranteed solution is full physical destruction. This is usually achieved using an industrial disk shredder that physically cuts the disk up into little cubes, and often involves a pass through a strong magnetic field. For government and military purposes, these cubes are often melted in a furnace afterwards for good measure.


How should an application store its credentials

Never hardcode passwords or crypto keys in your program.

The general rule of thumb is: the only credentials you should store on a user's machine are credentials associated with that user, e.g., credentials that enable that user to log into his/her account.

You should not store your developer credentials on the user's machine.  That's not safe.

You have to assume that anything stored on the user's machine is known by the user, or can easily be learned by the user.  (This is the right assumption: it is not hard to reverse-engineer an application binary to learn any keys or secrets that may be embedded in it.)

Once you understand this general principle, everything becomes easy.  Basically, then you need to design the rest of your system and your authentication protocol so that client software can authenticate itself using only those credentials that are safe to store on the client.

Example 1.  Suppose you have a Facebook app ID and key, associated with your app (i.e., associated with your developer account).  Do you embed the app ID and key in the desktop software you ship to users?  No!  Absolutely not.  You definitely don't do that, because that would allow of any of your users to learn your app ID and key and submit their own requests, possibly damaging your reputation.

Instead, you find another way.  For instance, maybe you set up your own server that has the app ID and key and is responsible for making the requests to the Facebook platform (subject to appropriate limitations and rate-limiting).  Then, your client connects to your server.  Maybe you authenticate each client by having each user set up his/her own user account on your server, storing the account credentials on the client, and having the client authenticate itself using these credentials.

You can make this totally invisible to the user, by having the client app generate a new user account on first execution (generating its own login credentials, storing them locally, and sending them to the server).  The client app can use these stored credentials to connect in the future (say, over SSL) and automatically log in every subsequent time the app is executed.

Notice how the only thing stored on a user's machine are credentials that allow to log into that user's account -- but nothing that would allow logging into other people's accounts, and nothing that would expose developer app keys.

Example 2. Suppose you write an app that needs to access the user's data in their Google account.  Do you prompt them for their Google username and password and store it in the app-local storage?  You could: that would be OK, because the user's credentials are stored on the user's machine.  The user has no incentive to try to hack their own machine, because they already know their own credentials.

Even better yet: use OAuth to authorize your app.  This way your app stores an OAuth token in its app-local storage, which allows your app to access the user's Google account.  It also avoids the need to store the user's Google password (which is particularly sensitive) in the app's local storage, so it reduces the risk of compromise.

Example 3. Suppose you're writing an app that has a MySQL database backend that is shared among all users.  Do you take the MySQL database and embed it into the app binary?  No!  Any of your users could extract the password and then gain direct access to your MySQL database.

Instead, you set up a service that provides the necessary functionality.  The client app connects to the service, authenticates itself, and sends the request to the service.  The service can then execute this request on the MySQL database.  The MySQL password stays safely stored on the server's machine, and is never accessible on any user's machine.  The server can impose any restrictions or access control that you desire.

This requires your client app to be able to authenticate to the service.  One way to do that is to have the client app create a new account on the service on first run, generate a random authentication credential, and automatically log in to the service every subsequent time.  You could use SSL with a random password, or even better yet, use something like SSL with a unique client certificate for each client.

The other rule is: you don't hardcode credentials into the program.  If you are storing credentials on the user's machine, store them in some private location: maybe a configuration file or in a directory, preferably one that is only readable by this particular app or this particular user (not a world-readable file).


Does a hacker know which IP they hacked?

Suppose someone hacks my computer (by any means, say a virus or trojan
like RAT), will they be able to know my IP address in real time? This
is about dynamic IP addresses.

Yes,By "hacking" your computer,i am guessing you mean popping a shell on the system,they would know the public/private IP address of the system when they receive the connect back or when they connect to your system by opening your system ports.


I knew nothing of this before reading your question, and decided to go and try to find an answer myself. Thanks!

It seems the particular attack you're probably referring to is one piece in an exploit chain that is used to install custom software onto an Xbox 360.

A full description of the attack is available here.

Essentially, an older version of the Xbox kernel had a flaw where memcmp was used to check the HMAC value. Downgrading to the older kernel version allowed an attacker to provide bogus hashes and measure the difference between a valid byte and invalid one - the attack described in the book.

Thanks for the interesting question; reading about the attack was very interesting, and I have a new book on my wishlist.


Can a Keypass file theoretically be cracked offline?

What about a password manager's database? You know nothing about the content of the file. How do you know you did manage to crack it?

This assumption is wrong. You don't know the entries, but in this case you know the software that created it. That software has a data format. It's even documented in the software project.
The format even contains data validation entries:

In KDBX 4, a data block is authenticated via a HMAC-SHA-256 of the ciphertext (an Encrypt-then-MAC scheme).

Thus you can easily validate the correct key.


HP software is klutzy to say the least.  Enterprise-level is just a catchphrase they used to sell it to your boss.  They will try to upgrade you to their management console products if you contact them about managing your end users in any way.  That might not be a bad thing if your boss is not too cheap to shell out more dough.
You might want to apply strategic pressure and make yourself an administrative way out logically by attempting to obtain other HP management software (it is 2am the intel remote management chip on the motherboard name escapes me).  You just have to cover your ass on this since for example the HP blade server as bad ass as it is even has security issues.  Yes I am reasonably sure if HP ties into your windows authentication it is a crappy implementationbecause even SMS has tricks to screwing up a profile come to think of it so make sure you document via email every single issue you are remotely concerned about.
The mcaffee software mentioned above is not going to solve your problem unless you get rid of a lot of the HP specific utilities shoved up in that OS as it stands today.  If you are in a small to midsized company you are going to spend a lot just in reconfiguration time alone.  ALL security vendors out there will say they are going to bring you into compliance, the reality is you do not need them unless you are in a time crunch because MS has spent a lot of time on this plus there are too many consulting companies dying on the vine right now.  Let your company pay you to do what they are going to outsource instead -- show them two machines clean and with your configuration only and see whether they willmgo with it or not.  Took two years of losing data and proprietary info to salesman and field engineer stupidity and a lawsuit over something we could not prove we never had in the first place before we took action.  Long story if I can elaborate further to back you up on something let me know going to konk out now...
   Hope that helps,
       iceberg


A nonce is a unique value chosen by an entity in a protocol, and it is used to protect that entity against attacks which fall under the very large umbrella of "replay".

For instance, consider a password-based authentication protocol which goes like this:

server sends a "challenge" (a supposedly random value c) to the client
client shall respond by sending h(c || p) where h is a secure hash function (e.g. SHA-256), p is the user password, and '||' denotes concatenation
server looks up the password in its own database, recomputes the expected client response, and sees if it matches what the client sent

Passwords are secret values which fits in human brains; as such, they cannot be very complex, and it is possible to build a big dictionary which will contain the user password with high probability. By "big" I mean "can be enumerated with a medium-scale cluster in a few weeks". For the current discussion, we accept than an attacker will be able to break a single password by spending a few weeks of computation; this is the security level that we want to achieve.

Imagine a passive attacker: the attacker eavesdrops but does not alter the messages. He sees c and h(c || p), so he can use his cluster to enumerate potential passwords until a match is found. This will be expensive for him. If the attacker wants to attack two passwords then he must do the job twice. The attacker would like to have a bit of cost sharing between the two attack instances, using precomputed tables ("rainbow tables" are just a kind of precomputed table with optimized storage; but building a rainbow table still requires enumerating the complete dictionary and hashing each password). However, the random challenge defeats the attacker: since each instance involves a new challenge, the hash function input will be different for every session, even if the same password is used. Thus, the attacker cannot build useful precomputed tables, in particular rainbow tables.

Now suppose that the attacker becomes active. Instead of simply observing the messages, he will actively alter messages, dropping some, duplicating others, or inserting messages of its own. The attacker can now intercept a connection attempt from the client. The attacker chooses and sends his own challenge (c') and waits for the client response (h(c' || p)). Note that the true server is not contacted; the attacker just drops the connection abruptly immediately after the client response, so as to simulate a benign network error. In this attack model, the attacker has made a big improvement: he still has a challenge c' and the corresponding response, but the challenge is a value that the attacker has chosen as he saw fit. What the attacker will do is always server the same challenge c'. Using the same challenge every time allows the attacker to perform precomputations: he can build precomputed tables (i.e. rainbow tables) which use that special "challenge". Now the attacker can attack several distinct passwords without incurring the dictionary-enumeration cost for each.

A client nonce avoids this issue. The protocol becomes:

server sends a random challenge c
client chooses a nonce n (should be distinct every time)
client sends n || h(c || n || p)
server recomputes h(c || n || p) (using the p from its database) and sees if this value matches what the client sent

Since the client includes a new random value (the "nonce") in the hash function input for each session, the hash function input will be distinct every time, even if the attacker can choose the challenge. This defeats precomputed (rainbow) tables and restores our intended security level.

A crude emulation of a unique nonce is the user name. Two distinct users within the same system will have distinct names. However, the user will keep his name when he changes his password; and two distinct users may have the same name on two distinct systems (e.g. every Unix-like system has a "root" user). So the user name is not a good nonce (but it is still better than having no client nonce at all).

To sum up, the client nonce is about protecting the client from a replay attack (the "server" being in fact an attacker, who will send the same challenge to every client he wishes to attack). This is not needed if the challenge is executed over a channel which includes strong server authentication (such as SSL). Password Authenticated Key Exchange are advanced protocols which ensure mutual password-based authentication between client and server, without needing some a priori trust (the "root certificates" when a SSL client authenticates the SSL server certificate) and protecting against active and passive attackers (including the "cluster-for-two-weeks" attack on a single password, so that's strictly better than the protocol above, nonce or no nonce).


When connecting to a VPN Provider, do other connected users pose a threat?

When you use a VPN provider, you need to trust that they have properly configured their servers. If they have not, there can be additional risk posed by other users of the service. For example:

Client-to-client visibility: OpenVPN (and likely other VPN software) has a client-to-client option that can be enabled on the server. This allows everyone using the VPN to "see" everyone else connected to the same VPN. If this feature is enabled, it could allow increased visibility of your system to an attacker or other malicious user.
DNS monitoring: You mentioned that your VPN provider has their own DNS servers. There is some additional risk of DNS based attacks. Or, if caching is enabled, potential fingerprinting of websites that other users have visited.

This is not an exhaustive list of vulnerabilities, but it should give you an idea of the risks if your provider's servers are slightly misconfigured. You can use this information to better reason about whether you need a VPN.


Why is STARTTLS used when it can be downgraded very easily?

The problem you describe is not the use of STARTTLS by itself but the optional use of STARTTLS. Mail systems can be setup so that TLS is required in which case the mail will not be delivered if STARTTLS will fail or if the peer does not offer support for STARTTLS in EHLO. Required STARTTLS is is as safe as required TLS from start.

The reason STARTTLS is not mandatory in most setups is because there are still enough systems out there which don't support TLS. The current transparency report from Google shows only 90% of all mails delivered from Google by TLS, which means that 10% of the mails are delivered to an MTA which does not support TLS.

Apart from that even with mandatory TLS the mail is not delivered in a sufficiently secure way. TLS is only used between the various hops during mail delivery and does not provide the end-to-end security which TLS provides in HTTPS. This means every mail server on the path has access to the plain text of the mail and can read and modify it, unless the mail is additionally protected with end-to-end protections like PGP or S/MIME.