What kind of email services should one use for online accounts such as paypal, adsense, youtube...?

As far as I am concerned, I try to use dedicated emails with full random passwords stored in a password manager. Random passwords are brute force resistent, and dedicated mail accounts make it harder to establish correlations between my different accounts.

As email provider, I sometimes use my ISP, but more often any other free email provider. I do not trust any of them more than the others to respect my privacy. All I hope is that their datacenter is secure enough to protect my account from script kiddies and ordinary bad guys.


For any reason, your database may be compromised and its data may be obtained by someone else. If the passwords are in what we call plain text, you will have leaked a piece of sensitive information that your users have trusted you with: their password (which is very likely to be a password shared in multiple services). This is a very serious issue.

Instead of plain text, passwords are typically hashed with an one-way hashing function. If the cryptographic function used for the hashing is strong, then the passwords are much safer, because even if someone gets their hands on your database, it's computationally infeasible to calculate the passwords (given only the hashes).

On the other hand, the hashed information remains useful to you: Because the same hash function will always yield the same hash for the same input, you can still hash any attempted password and compare the result to your saved hash to verify a user's authentication attempt (without knowing the correct password beforehand).

Of course, just hashing is not enough nowadays. There are lookup attacks that often make decryption (of hashes created from predictable passwords) very feasible. To counter these attacks, each password is hashed together with a unique randomly generated piece of input (called salt). The salt is stored in plain text in the database and it doesn't have to be secret, because its main purpose is to render precomputed hash dictionaries useless.

Almost all serious platforms use hashing and salting to store their users' passwords (unless they make use of something different but comparably secure that I'm not aware of). Incidentally, this is exactly why you can reset your password in various services but almost never recover it: The hash can be overwritten by the system, but it can't be decrypted.

You should by all means do the sane thing for the sake of your users' security and salt-and-hash your passwords. There are plenty of resources online that explain the process and the pitfalls in detail. One of them is "Secure Salted Password Hashing: How to do it Properly".


How to avoid DDOS against Kerberos Authentication Server

Most distributed denial-of-service (DDOS) attacks are simple "throw data at the server faster than its connection can handle" attacks, and consequently cannot be dealt with at the application level.  Rather, they're mitigated at the ISP level, typically by blocking the attacking computers.

Non-distributed attacks, on the other hand, can be mitigated at the application level.  Look for ways that a client can make the server use far more resources (CPU, memory, etc.) dealing with a request than the client uses in making them: those are the possible attack vectors.  Once you've identified them, you can figure out how to deal with them through techniques such as rate-limiting, making the server more efficient, or shifting load to the client.


How Can I Process Untrusted Data Sources Securely?

It all depends on what you actually do with the data. A bunch of bits sitting on a disk is just that: a bunch of bits. It needs to be somehow executed in order to become malware and pose a threat to your network.

This could be done in a couple of ways:

windows allows autorun on removable media. Mitigation: change ingestion machine to Linux or carefully configure windows
manual execution: employees can do it by accident. Mitigation: restrict employees account, for example, make the files read-only by default. This doesn’t protect from malicious actions, only from accidental ones.
Data on the disk can exploit a vulnerability in file system drivers. This is pretty unlikely, file system drivers are tested pretty well and any vulnerability here is critical and would be a very expensive 0-day (so it wouldn’t be used against you).
Mitigation: you should automatically install security updates. Another way to protect against this is to use user-space file system drivers. AFAIK they are less well tested, less stable, and less performant, but any successful exploitation will give a user-level (and not kernel-level) access. You’d have to think about this trade-off by yourself.
Lastly – the data can exploit vulnerabilities in other software that you use to process the files. This is the most likely option, arbitrary code execution vulnerabilities are regularly discovered in software like pdf readers. Mitigation: keep your software updated, and configured to a high security (don’t allow macros in MS Office, etc.).

Additionally, you can contain every file processing step in a VM and reset it to the known good state after each workday. This would be pretty inconvenient but would offer some additional protection, especially if you disable networking on the VM.

I wouldn’t get my hopes up about antiviruses unless you’re actively executing supplied files they wouldn’t offer much protection.


How content-type:image can lead to infected JAR file?

There's a longstanding issue (feature?) with IE doing Content Sniffing instead of just respecting Content-Type; this still exists largely for historical reasons. You do have the ability to disable it - MIME Type Detection references the Feature Controls - if you want to make your machine(s) more secure. It is still marginally useful since a common 'fix' server-side for unknown binary file types is to server as application/octet-stream, which may cause things to not work as expected (videos may download instead of play, for example).

It's likely that this particular exploit just happens to use a gif because it'll get past email scanners, etc. more easily embedded in an  tag in an email.


What will disabling third party cookies block?

Disabling 3rd party cookies is largely a privacy measure.

Cookies are restricted with a Same Origin Policy (SOP), which essentially mandates that a site on domain A can't set a cookie for domain B, and your browser shouldn't send cookies for domain A when visiting domain B. This is largely for security reasons: you don't want sites being able to read session cookies from other domains!

Advertisers and analytics companies have, of course, found ways around this. Instead of setting a cookie for their domain, they include a small resource (usually called a "pixel" tracker) on the page, from a 3rd party domain. The HTTP response from the 3rd party domain is free to set cookies for its own domain, so it generates a unique ID for your visit and sends it as a cookie. You then visit another site, which also uses that same tracker pixel. The same 3rd party domain can read back that cookie because it's part of the same origin, and therefore track that you came from one site to another.

Blocking third party cookies stops this behaviour. It prevents the 3rd party resource from setting a cookie because it was fetched in the context of a different domain, i.e. the page you're viewing. The implementation essentially modifies the cookie SOP to limit the cookie origin to the domain of the page you're viewing.

Keep in mind that this isn't infallible, though. One work-around that is commonly used is to generate a unique resource (e.g. a dynamically generated CSS file with a unique ID inside it) and serve it with cache-control headers set to ensure caching. Modern browsers hash the contents of the cached resource and send that hash as part of a HEAD request to sites to see if they've changed and need to be re-downloaded. The tracking server then takes that hash and looks it up against its database of unique IDs, and works out which one you were. Evil, no?


Has there ever been a country that implemented whitelist-based internet censorship?

North Korea comes to mind. Most North Korean users only have access to Kwangmyong national network controlled by the government. This can be viewed as an extreme case of a whitelist-based approach to censorship.


It seems using key decryption found in OpenSSL isn't really going to do it. If you are using a Linux box that has apt-get you can apt-get install pyrit, which is designed to crack WPA2 using various techniques. Even if it doesn't crack, you will get a better idea how a cracking application like this works simply by typing the command followed by the -h option.


The little circles are indeed XOR.

The size of the blocks depend on the cipher you use, for instance AES-128 has a 128 bit block size (NOTE: the 128 in AES-128 stands for the key size, not for the block size). Note that CBC is Cipher Block Chaining, an operation mode how you use a cipher, not the cipher itself.

The XOR operation is logically on the bits of the plaintext. Everything, also what you are referring to as "text", is internally in any digital computer represented by bits (or bytes=8 bits).

Once the encryption or decryption is done, all bits are put after another. So it would be text from ciphertext 1 then following ciphertext 2 and so on. Depending on byte order the representation might also be the other way around.


How to keep a shared web hosting server secure?

It’s probably impossible, but you can make it harder for an attacker to succeed.

Strengthen your defenses:

Security harden the system (maybe referencing one of the following checklists)

  http://iase.disa.mil/stigs/checklist/ (look for UNIX Security Checklist)
   https://benchmarks.cisecurity.org/en-us/?route=downloads.multiform

Add:

  grsecurity
   Security-Enhanced Linux
   AppArmor

A decent comparison of the above tools is described here:
http://www.lifelinux.com/selinux-vs-apparmor-vs-grsecurity-345.html

Keep up to date on security patches.

Get visibility:

  Deploy a HIDS (e.g. OSSEC) to help you detect when users are behaving bad.

All of the above will require continual effort.  That is security.


Can my computer run malicious Javascript due to Man-in-the-middle attack on the connection with HTTP site?

A man in the middle can answer the plain HTTP requests sent by the client on behalf of the server. This includes modifying the original response of the server to  include Javascript which gets executed in the context of the page. Or the attacker might serve some malware to the visitor. It does not matter at all in these cases that the original site had only static HTML, all what matters is what the attacker serves. In fact, the attacker might serve completely different content without even contacting the original site.


Asymmetric crypto to store credentials in HTML LocalStorage

It sounds like you're making this more difficult than it has to be.

Clearly a random, server-issued key which corresponds to a server-side data element is by far the best solution, and in practice the only solution that any reputable organization employs. But since you want something different, here you go:

Upon login, you encrypt the login information server-side, with salt and some HMAC (and possibly a timestamp), base64 encode the result, and there's your persistent token that you issue to the client. Ideally you should also tie the login to the device somehow; perhaps some sort of static device ID that gets sent to the server and encoded into it.

Then when you need to re-authenticate, your client passes this token to the server, which your server will decrypt, authenticate, and then issue your app a session key as normal.

It's not quite as good a solution as a random, opaque authentication token (which is valuable only as it corresponds to some server-side datastore), but you said that this is impossible for some unknown reason. I would argue that if something as simple and useful as this is impossible, then you're using the wrong software.

As for using asymmetric crypto and browser-based RSA for storing authentication tokens, I can't come up with even one scenario where this is appropriate. But sometimes complexity for complexity's sake has it's own allure.


Where can I find the detailed manual page for gpg --list-secret-keys output

[sec] - The following is a secret key
[ssb] - The following is a secret sub key

The meaning of # after each of these is that the key is not usable, if say, you used the export subkeys option or if the key is otherwise taken "offline".

The meaning of > is that the key is stored on something like a smart card.

You can find more info here at Ubuntu's man page for GPG
and the documentation you reference has been moved to here at GnuPG.org.


How do you verify if an app is using secure comms?

You only need to mount a MitM attack if you intend to decrypt the traffic. if the application is using a standard encrypted protocol (SSL/TLS, SSH) then you can simply record the connection (for instance, using tcpdump) and then feed the result to a descent protocol analyser (i.g. Wireshark) and it will tell you if there is a secure handshake and what options where used.


What type of security should I set up for a domestic webserver?

Yes, SSL will be necessary (well... technically, you can reimplement all your encryption need in the application layer, but it'll be very, very hard, it'll be much easier and more secure to leave writing the the encryption layer to the experts).

Yes you can use self signed certificate for this purpose since you control both the server and client.

However, server side SSL isn't sufficient for authentication. You'll either need to add authentication (e.g. some sort of Bearer token or HTTP Basic Auth), or use SSL Client certificate (mutual authentication).

Alternatively, you can use a Intranet VPN (not to be confused with Anonymizing VPN) to solve the encryption and authentication problem. Instead of trying to solve the prosblem at the endpoint level, instead you setup your own private VPN Intranet to connect to your LAN remotely.


How is JSESSIONID determined in this CSRF test?

But how does it determine JSESSIONID? I can log in and close the
  browser windows and the page still works as long as my session is
  still valid. Seems the server is telling the browser what its
  JSESSIONID is?

The server sends JSESSIONID to the browser in an http response with a set-cookie header.

Here is an example:

HTTP/1.1 302 Found
Server: nginx/1.4.6 (Ubuntu)
Date: Mon, 23 May 2016 19:48:35 GMT
Content-Type: text/html; charset=utf-8
Connection: close
Location: https://freezerpro/signin
X-UA-Compatible: IE=Edge,chrome=1
Cache-Control: no-cache
Set-Cookie: JSESSIONID=3a64adc78f2dae266c99767c6686bc0d; path=/; HttpOnly
X-Request-Id: d09eafd83135da8ad1f261d67d380c84
X-Runtime: 0.008982
X-Rack-Cache: miss
Content-Length: 95

And then the next request from the browser to the server has that same sessionID, linking it to the already established session:

GET /signin HTTP/1.1
Host: freezerpro
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Cookie: JSESSIONID=3a64adc78f2dae266c99767c6686bc0d
DNT: 1
Connection: close


Can we determine if a device providing a hash was tampered with to produce falsified hashes?

Normal hashing methods act as integrity checks for checking if a file is corrupt. In this context corrupt does not mean tampered with, but that something got lost in transit. It's totally possible for an attacker to change the hash on a compromised device.

To add to Douglas's solution to use an external log server: A solution to this is to use an HMAC. Here you create a hash with a secret. If both parties share the secret and the secret is now known to the attacker, you can detect if the file has been tampered with. However, if the device is compromised the attacker might got a hold of the secret, which would destroy this security layer. The same goes for signing with a secret key.

https://en.wikipedia.org/wiki/Hash-based_message_authentication_code

If you can make it expensive you can start thinking about an HSM, which is a device created for the task you are describing. From Wikipedia:

  HSMs may possess controls that provide tamper evidence such as logging
  and alerting and tamper resistance such as deleting keys upon tamper
  detection.

https://en.wikipedia.org/wiki/Hardware_security_module


How can I block bots that consistently hit the same URLs?

It appears that Fail2ban fits your scenario perfectly. It is rather configurable so you should be able to setup what you need by consulting the documentation a little.


I suspect you may have conflated two things here, as @Steffen Ulrich indicated:

on one hand, you are talking about an IDS, which uses signatures, and could detect attacks. But most IDSes (AFAIK) don't treat WLAN distinctly - on the contrary, most IDS signatures (and certainly those from Emerging Threats) focus on IP and application layer - i.e. they look at traffic coming from connected WLAN clients, and indeed, coming from any network connected device. So an IDS will allow you to build what you want, but will do very little to protect your WLAN as such.
on the other hand, you are talking about detecting wireless intrusion (I assume), which is a completely different thing. Per https://en.wikipedia.org/wiki/Wireless_intrusion_prevention_system:

  In computing, a wireless intrusion prevention system (WIPS) is a network device that monitors the radio spectrum for the presence of unauthorized access points (intrusion detection), and can automatically take countermeasures (intrusion prevention).

In other words, you need to choose:

if you want to detect network 'attacks', an IDS is the correct solution, but doesn't (fundamentally) care about WLAN vs any other network. It is looking for actual 'attacks' as opposed to looking for signs of wireless intrusion. In other words, this is what will help you detect when something on your network does something.
if you want to detect wireless intrusion, you need something that monitor for rogue access points and clients, based not on signatures, but (in essence) on whitelisting. This will help you detect when something is trying to either join your network, or trying to steal clients from your network.

In the long run, both may have their place/use, but you do need to ensure you are picking the right tool for the job you are trying to do.


Why Aren't Credit Card PINs Required For Online Transactions

Consider the threat model -- today, a rogue website (or one taken over by an attacker) can siphon off your credit card number and make fraudulent purchases.

Ok, so we implement a PIN, required for online purchases.

The same rogue website just asks you for your PIN too, and then uses those to make fraudulent purchases.

The method they use in Europe (IIRC) uses the PIN in conjunction with a chip on the card, which prevents the website from being able to give up that authorization to an attacker. I'm not sure of the actual method, but I'd imagine the PIN unlocks a certificate on the chip, and the certificate is used to sign the transaction.


Security concerns with external MySQL access using tunnelling

Well, assuming you are using SSH to access the server anyway, that tunneling is effectively already in place. I would suggest doing a few things to prevent unauthorized access to your VPS:

Give a non-privileged user "sudo" access. Make sure you do this first if you decide to also implement step 2. Otherwise, you'll lose remote access to your server.
Prevent Root Login over SSH. Now you'll only be able to login remotely as the unprivileged user in step 1.
Change the port SSH listens to. I personally use a port number over 10000 that ends with "22". This helps avoid drive-by hacking attempts that hit the standard SSH port (22).

The combination of these three changes will mean that you will need to login as an unprivileged user first, using the custom port you chose in step 3. Then you can issue privileged commands using the sudo command. You'll also need to use the custom port and unprivileged user for SSH tunneling of your MySQL client.


Can we identify if someone is keeping an eye on our computer usage?

It depends on what exactly you were using.

Direct inspection

computer: if you're using a public (library, etc.) computer, you can check its usage history - browser history, and so on. Keep in mind that most such systems ought to use, and often do use, virtual/sandbox systems such as SteadyState, that erase all traces after you log out. So eye-keeping at the computer level might be impossible to detect. Even more so if the data is sent and used elsewhere (e.g. keylogging, screen capturers etc.). You may detect the presence of such software, though.
network: you can do zip, unless you have access to the management interface and/or hardware. Your access point might be cloning all your traffic for subsequent exploitation, and you wouldn't be aware of that (which is also a very good reason never to use "open" wifi networks more or less willingly supplied by more or less known parties).
facilities: very much like the network. You ought to have access to camera logs and the like; nobody would ever let you.

Indirect methods

Check out access patterns and access times to whatever services you're using. For example, GMail records the IP address of your last visit(s) to their systems.

Good practices

If you really had to use an insecure path, change your relevant passwords and every access code that may have been rendered insecure, as soon as you can. If you keep passwords and license codes on a cloud account, use two accounts with different passwords. That way the "password account" will only be made insecure if you actually have to use it, not just if you happen to be checking your email for other reasons.

(For holidays, etc., you might set up a "throwaway" write-only account: when going on holiday you can set up a forwarder from the real account to the throw-away one; when coming back, you can instruct the real account to also read any incoming from the expendable account (be careful not to set up a loop...!). That way, people sending you email on the throw-away account would still get read; at the same time, the expendable account has nothing worthwhile on it).

Social engineering

You could try and lay some bait. For example say that I have a web site of my own, whose access logs I control and can check. Then I happen to use a network where someone could be eavesdropping.

I could send an email to a nonexistent account, or an account that's mine only but not immediately recognizable as mine:

John,
this is the documentation we talked about. The zip file is encrypted
and the password is 'shish-kebab'. Man, this is HOT. Keep it for yourself,
one could make real money here.
http://myownwebsite.com/for-john-material.zip

...ordinarily, nothing would happen. The email will never arrive, and if it did, I'm the only one who would read it, and I would do nothing. The zip is not even there - it never was: it never even existed.

So if I found a 404 error in my Web logs, stating that someone tried to access a file whose name ought to be known to no one, then this would tell me that someone snooped my email -- and would also tell me his IP address, time of day, maybe his browser User-Agent (supposing I could trust it) etc. .

(I could even set up a page designed to send me a warning in real time).

The same thing can be done on a computer, if you know you should be the only one having access to any given section of it: set up a document there, remember never to open it, and check out its last access time. Also, you can usually check event logs and access information (if and how depends on your operating system, though).

Screen activity grabbing

An easy way that is usually enough to spot screen grabbing consists in looking up the network properties, and specifically the network traffic counter. In a pinch, look at the network activity LED which is usually near the plug. Screen grabbers work in one of two ways: either they photograph the screen at fixed intervals (difficult to spot, since it's not under your control) or, to save bandwidth, they do so whenever the screen changes, and often only transmit the changed areas.

So if you open the Network Properties, you'll see that the traffic counter is steadily going up in fits and starts (Windows Update, BITS and various services are always running), usually not very fast. If you were to shuffle icons around, this should have no effect on the network (unless you operated on a network folder), normally; but if the screen is being grabbed, your moving an icon or resizing a window would trigger a screen update, and you'd see the network traffic going up in sync with your actions.


Does it take longer to brute force a password starting with z than one starting with a?

In general, attackers are adaptive. They know what people think. If users tend to begin their passwords with 'z' then attackers will start their brute force with that letter.

Any specific strategy, such as choosing a 'z' as first letter, may give you an edge over the attacker only as long as the attacker does not know it; so talking about it on a public Q&A site is not the smartest move ever. Moreover, attackers always have the option to try passwords in a random order, which ensures a non-worst case for the attacker. When there are N equiprobable passwords, the average cost for the attacker is N/2 tries, and by trying the passwords in a random order, the attacker achieve that cost regardless of your choosing strategy.

The important point is that password protection is stochastic. For any specific password instance, an attacker can get lucky; he can also be especially unlucky. We thus analyse password resistance based on the password generation process, not based on a specific password instance: the generation process tells us what will be the average success rate of the attacker. "Average" is the crucial word.

Take note, too, that probabilities rule your life: whenever you get out of your home, you are taking the probabilistic bet that you will not be struck by lightning or bitten by an rampaging Rottweiler. You accept this because you instinctively perform a cost/benefit analysis and consider that such events are sufficiently improbable that they don't outweigh the benefits of being able to walk outside.

That concept just applies to passwords as well: you will rely on your password generation process having sufficiently high entropy, i.e. making attacker's success rate sufficiently low, that attackers will not even try (or won't succeed with high enough probability). In that sense, "aaaaaaaa" is not stronger or weaker than "zzzzzzzz", as long as the method you use to generate your password can produce both with equal probabilities. The strength of a password is not in what it is, but in what it could have been.


PCI Compliant Key Management solutions that don't cost a fortune

One of the main difficulty with good key management is secure storage of encryption keys. If you look at what the NIST is saying on this subject (SP 800-57), you basically have three options:

Use HSM
Use physical security (put your key in a safe)
Store your key directly on the system, encrypted by a Key-Encryption-Key (this option is frequently used, but does not solve your problem, because your top KEK has to be securely stored as well !)

You already stated that HSMs are expensive so you still have the safe option. The main problem in this case is that your servers cannot get the key automatically when they need it, so you have to make sure that:

Your application needs to get the key only once (it is then stored in memory)
You can have someone type the key each time you boot your application

Obviously, you still have to define secure procedures for every aspect of the key management, but in certain cases, it can be a viable and cheap option.


What approaches are to detect DoS attack in IDS/Firewall?

DoS attacks are simply massive floods of data being sent to your server. Something as simple as a Nagios rule can be set up to detect an abnormal traffic load.

Here are some example rules for basic traffic stats monitoring:

"If I'm receiving more than 80Mbps of incoming traffic, send an alert." - useful for known average traffic rates that don't vary much.
"If my incoming traffic rate exceeds 60Mbps and the average incoming traffic rate over the last 10 minutes exceeds the average incoming traffic rate over the last 4 hours by more than 70%, send an alert." - Useful for situations where traffic varies, but a reasonable baseline threshold is available.
"If the number of SYN packets received in the last 5 minutes exceeds the number of ACK packets received by a factor of 10 or more, send an alert." - Useful for catching SYN floods.

If we consider IDS rules instead, we can look into more specific rules about individual clients:

"If any one IP has contributed to 100MB or more of traffic in the last 20 minutes, send an alert." - Useful for catching individual DoS attempts, or possible data exfiltrations. Obviously this won't work too well if you're offering large files to users.
"If any one IP has sent more than 40MB of UDP traffic in the last 10 minutes, send an alert." - Useful for catching UDP floods, since UDP traffic isn't really expected on most web servers.

Obviously these are just examples.

The difference between an IDS and a firewall is primarily that an IDS is passive (i.e. it looks at traffic and produces alerts when bad things happen) and a firewall is active (i.e. it drops packets that match a rule). However, a firewall usually has much more simple rules, often based around metadata like the source IP, protocol type, port number, TCP sequence number, etc. An IDS usually focuses on the payload, rather than the packet. Some firewalls include IDS features, and an IPS is essentially a combination of the two that can manipulate traffic based on more complex rules.

In terms of flow analysis vs. packet analysis, both styles of mitigation work, but they work even better when combined. Your flow rules are likely to catch DDoS attacks once they've started to affect your system, whereas your packet analysis rules are likely to catch DDoS attacks in their infancy. The false-positive rate on packet analysis is quite high, so using both as an indicator makes more sense.


Checking the reverse IP address to find all DNS records

In order to perform a vulnerability assessment you first need an inventory of what you are assessing. Reverse ip lookups for dns entries are one way to start building that inventory.


Is it okay to keep Windows 7 for gaming only?

From a general perspective it is safe enough.

I know that many times you will have to run an old OS due to compatibility issues with software, in your case - games. I still practically use XP due to that in some scenarios and I do that in a very safe manner.

In your case things may be easier than average: on the online gaming part you can allow only the ports used by the gaming services/servers and you can secure everything else. You may even close-up browsing-related capabilities completely or block most of the TCP ports with very few exceptions.

In this one should not take game vulnerabilities into account since those are not breaches of the OS, but of the games. On the OS part you should be pretty good overall for many years ahead.

In the specific situation of Windows 7, things are looking good. There are still 2 more years of actual support of it (see the MS descriptions about this) and by the end of this period Windows 7 will already have a low enough coverage not to be a primary target of exploiting anymore.

Even if universal exploits are found (that are cross-versions and affecting any Windows OS) most of them will still be able to be community patched.

So I would not worry. Gaming on Windows 7 will still be good for years and the obvious choice of old enough games. Even if groups like GOG try to make most games work with Windows 10, older ones will work better on older OS'es. For a specific older game, you won't have any advantage whatsoever by using Windows 10 from a security perspective or any other.


How to "Pass the hash" when LM hash is disabled?

You need either of the hashes in order to 'pass the hash'. Here is some further reading for you if you're interested in learning more about it.

https://www.sans.org/reading-room/whitepapers/testing/crack-pass-hash-33219


Is it wise to log failed login attempts of non-existing accounts?

One drawback to logging failed user attempts is that some users type their password into the username field and press submit.   Sounds silly but it has happened enough times to be a concern.

This can happen with typing too quick, a password manager, or some other automated means.


When software needs to use SSL/TLS, it commonly wants to use a list of Certificate Authorities. There may be software that simply always warns for every unknown certificate, but like you said, Firefox and Chrome have a list of CAs.

Where they get this list depends on the software. You can google this, you know.

Mozilla maintains an own list of CAs (for Firefox, Thunderbird, etc.)
Chrome uses the CA list from the operating system, or at least on Windows I read.
Opera maintains an own list of CAs it seems.
Safari uses the OS's list (Apple's on OS X and Microsoft's on Windows).

Then about your question regarding how this list is obtained: You are right, if the download was not verified to be secure (in a secure way), then all communications from thereon are inherently insecure. When you are downloading a Linux distribution and I replace your download with one that has an altered CA list, then yes, I could read all your HTTPS communications. It's probably much easier to just install malware though.

Note that a checksum alone is not the ultimate solution: the checksum must be obtained over a secure connection (e.g. https), or else that too can be altered.

It's funny: if you need to obtain the checksum over https, where did your current browser (or OS) get a CA list? Somewhere you always have to trust someone or something (such as the shop you bought Windows from), besides the trust that you put in CAs.


Replacing a TLS cert when the old one is pinned (HPKP)

You should ALWAYS have two (or more) pins in your headers: one for your current certificate, and one (or more) for the backup certificate(s) (held separately from current one, best offline).
If your current certificate was not compromised, you don't need to touch the pins or issue new certificate - you can simply renew existing certificate (ask CA to issue new CRT using the same CSR as previously).
If your system was compromised you can switch to backup certificate you've had pinned (for at least max-age) ANY TIME - UA will accept it, because the pin is valid (was previously present in headers).
You can ask any CA that is trusted by the client to sign your CSR (current or backup).
If you want to add new pin you need to wait max-age period (usually 60 days) before using certificate that matches it, to eliminate risk of UA rejecting connection. See scenario below and note the differences between clients X and Y:

day 1: you configure pin A + crt A, set max-age to 60 days,
day 2: client X connects and learns A is safe for 60 days,
day 3: client Y connects and learns A is safe for 60 days,
day 20: you add pin B to the headers,
day 21: client X connects (he trusts A) and learns both A and B are safe for 60 days,
day 40: you switch to crt B,
day 41: client X connects (he trusts both A and B),
day 42: client Y rejects the connection - he didn't manage to learn new pin from trusted A (like client X did), so he will reject everything except A until day 63.

If still in doubt, see section 2.6. Validating Pinned Connections and Appendix B. Deployment Guidance in RFC 7469.


Blocking some part of a website is easy with software like privoxy, or you can ban entire domains with dnsmasq. Both are available for most, if not all, open source router firmwares, like TomatoUSB or DD-WRT. For a good router, I recommend something like the Asus RT-N66U.


How does add-on for the Firefox with a custom proxy server prevents info from Google?

Google sharing worked as a "search exchange".

You'd offer your computer as a restricted proxy (only for google) for other users, and use proxies of other users who did the same for your searches.

The main trick was the use of https - SSL sessions were still maintained by your computer and you could still verify google certificate - only the raw tcp session were proxied.

That way users still kept their searches confidential. Sadly google cracked down on this (because it was used by bots for automated searches) - quality of service degraded to that of google behind Tor, meaning a LOT of captcha, and mandatory cookies for all "exit IPs" - effectively all users in of the google sharing IP anonymity set. Instead of fixing this, moxie discontinued the service.

I'm currently in the middle of reviving the concept, with tit-for-tat (search-for-search) implementation, so that bots can't ruin the service again.

EDIT: As per request expanding the answer. Just to clear up how it exactly worked, the life cycle of each request went like:

searchclient's http_POST-> tunnel server <-http_GET_longpoll proxyclient->google

The HTTP POST / GET pair serve just as mere TCP tunnel (the tunnel server was written in python with twisted and they were federated IIRC).

What alternative is there at the moment? Just use Tor. You'll have to fill captcha now and then, and google will keep track of your search session (ie they could group searches together as belonging to one person), but they can't identify who it is. If you drop breadcrumbs through searches, switch identity in tor browser every time you do.

As for the proposed reincarnation of google sharing, the idea is to run some sort of overlay P2P network (no more tunnel server as an entry hop to proxy) - we have WebRTC these days - it didn't exist in 2010.

The tit for tat mechanism to prevent bots works on proxied data usage (because you can't guess how many searches were done over ssl, only the amount of results). The proxies will talk one to another similiar to how bittorrent works - they'll be reluctant to proxy for somebody who didn't proxy for us first, with some random altruism to bootstrap the exchange.

This "karma" could be also delegated from common friends, so one is not restricted only to peers being proxied for in the past.

The peers generally knowing each other isn't perceived as a problem as it would be in Tor, because nature of this traffic would be to switch proxy per every search. At best an adversary could uncloak one or two of our searches, but not most. In the original Moxie's design, the intermediate servers could uncloak all clients, assuming google would be complicit adversary. This was deemed inpractical (and still probably is), as google would have to log packetdumps of all SSL traffic they get, so they could cross check with packet captures from tunnel server.

The advantage of exchange compared to Tor is mainly having comfort of search near to that of direct connection (assuming your upload bandwidth can accomodate the tit-for-tat exchange) and being less suspicious overall as anything originating from Tor or even well known VPN services is sure under heavy scrutiny.

Ordinary user IPs is a drop in the ocean.


Chances of recovery of data from iPhone 5s if memory has been overwritten 35 times?

Doing this is complete nonsense.

All data on a modern iPhone (5s upward) is encrypted with a key which is derived from a key inside the CPU, another key stored in two copies in the flash memory, and usually the passcode is used as the third key.

All you need to do is erase the two copies of the second of these three keys which is stored in the flash memory, and it's game over. You cannot find the decryption keys anymore, they are 256 bit keys, and they are different for every single file - cracking 256 bit keys is considered physically impossible, and you would have to repeat this for every single file.

Apple also uses an API that can erase physical blocks on a flash drive, so you can safely assume that overwritten encryption keys are not recoverable


vmnat.exe is VMware's virtual networking service: all network data going to or from a guest OS using NAT networking passes through it.

Norton can't see inside your VM.  Instead, when a program inside the VM does something, Norton sees the virtualization software performing that action.  In this case, when your virtualized browser tried to download the "Ransomlock Website 7" malware, Norton saw vmnat.exe downloading it, but didn't see that the data would then be handed off to a virtualized OS that couldn't be harmed by it, so it blocked the download.

Yes, it's possible for an attack to break out of a virtual machine, but it's very, very rare.


Compromise of refresh token would cause more harm than compromise of access token.

You can employ various techniques to make it more secure.

You can get the idea by learning about one of the standard technique which is recommended for "The OAuth 2.0 Authorization Framework". Please refer the RFC.

You can separate the concern of access and authorization by maintaining separate resource server and authorization server. You can use only access token (and not refresh token) to access resource. You can use only refresh token (and not access token) to communicate with authorization server. This mitigates the risk of refresh token getting compromised.

Secondly, it is easier to detect if refresh token is compromised.
Let's say a refresh token is comprised and is used to generate new access tokens. Once this refresh token is revoked, all the access tokens generated already and latter will get invalidated. As such only 1 party will be able to access the resources using access tokens generated using the single valid refresh token. If multiple users are participated, they will go on invalidating each other. In the process detection of refresh token compromise gets easy.


Why local variable is not overwritten due to buffer overflow?

Alignment.  The compiler is allowed to place local variables on the stack in a way that the alignment to the CPU words is better.  In other words, there is nothing that forces the compiler to place local variables one after another on the stack.  Actually placing local variables one after another would be saving a couple of bytes in program size for a considerably big penalty in processing time.

Allow me to use plain C instead of C++ to explain 'cause it is much easier to drop it into GDB.  Program converted to plain C, let's call is pp.c:

#include <stdio.h>
#include <string.h>

int main() {
    int i = 20;
    char var[4];

    strcpy(var, "12345678901");
    printf(" var is : %s\n", var);
    printf(" i : %d\n", i);
    return 0;
}

Note that the string I used is of the same length:

"12345678901"
"biiiiiiiyee"

Let's compile it without optimizations, just in case:

gcc -O0 -g -o pp pp.c

And now let's look at the program running:

$ gdb -q pp
Reading symbols from pp...done.
(gdb) list
1   #include <stdio.h>
2   #include <string.h>
3
4   int main() {
5       int i = 20;
6       char var[4];
7
8       strcpy(var, "12345678901");
9       printf(" var is : %s\n", var);
10      printf(" i : %d\n", i);
(gdb) break 8
Breakpoint 1 at 0x4004fa: file pp.c, line 8.
(gdb) break 9
Breakpoint 2 at 0x400510: file pp.c, line 9.
(gdb) run
Starting program: /home/grochmal/tmp/pp

Breakpoint 1, main () at pp.c:8
8       strcpy(var, "12345678901");

OK we are just before the overflow happens, let's see where the stack is and where the variables on the stack are:

(gdb) p $rsp
$1 = (void *) 0x7fffffffe860
(gdb) x/16x 0x7fffffffe860
0x7fffffffe860: 0xffffe950  0x00007fff  0x00000000  0x00000014
0x7fffffffe870: 0x00400550  0x00000000  0xf7a5c291  0x00007fff
0x7fffffffe880: 0xf7dd0798  0x00007fff  0xffffe958  0x00007fff
0x7fffffffe890: 0xf7b9cc48  0x00000001  0x004004f6  0x00000000
(gdb) p &var
$2 = (char (*)[4]) 0x7fffffffe860

Very good, var is really at the top of the stack (0x7fffffffe860) but i is not 4 bytes later.  i is at 0x7fffffffe86c, 12 bytes later (i is 20, i.e. 0x00000014).  Let's see what happens next:

(gdb) cont
Continuing.

Breakpoint 2, main () at pp.c:9
9       printf(" var is : %s\n", var);
(gdb) x/16x 0x7fffffffe860
0x7fffffffe860: 0x34333231  0x38373635  0x00313039  0x00000014
0x7fffffffe870: 0x00400550  0x00000000  0xf7a5c291  0x00007fff
0x7fffffffe880: 0xf7dd0798  0x00007fff  0xffffe958  0x00007fff
0x7fffffffe890: 0xf7b9cc48  0x00000001  0x004004f6  0x00000000

The buffer does overflow!  But not far enough, we need 1 extra byte (remember that that 0x00 is the null terminator) to reach the place in memory where i is located.  If we change our strcpy to:

strcpy(var, "AAAAAAAAAAAA\x39\05\x00");

You get to overwrite i:

$ gcc -O0 -g -o pp pp.c
$ ./pp
 var is : AAAAAAAAAAAA9
 i : 1337

It is not easy to guess alignment, it depends on CPU and compiler.  Most (white/gray/black) hats do it by trial and error, or by compiling the program in the same environment it is run and then looking at it in a debugger (as we did above).


How is truncation according to PCI DSS secure?

I think it makes more sense in the context of how much extra information is being given away, rather than how easy it'd be to brute force the remaining digits.

A PAN is not entirely a random value, it's made up of:

  a six-digit Issuer Identification Number (IIN) (previously called the    "Bank Identification Number" (BIN)) the first digit of which is
  the Major Industry Identifier (MII),
  a variable length (up to 12 digits)    individual account identifier
  a single check digit calculated using    the Luhn algorithm

http://en.wikipedia.org/wiki/Bank_card_number

Therefore using this information:

  My company's database supplies me with name, address, card type,
  truncated PAN, and expiry date of the card/holder

You could probably narrow down the first 6 digits pretty easily to quite a small set of possibilities.

That only leaves the last 4 digits, one of which is a check-digit and therefore doesn't contain any additional entropy.

So basically you're only giving away 3 digits, even if all 10 that are allowed are exposed.

  this leaves only 100,000 card numbers to brute force in order to get
  the one I want

I'm guessing it would be fairly hard to execute such a brute force attack as most payment processors would lock you out very quickly.

PCI DSS also says:

  Note: It is a relatively trivial effort for a malicious individual to
  reconstruct original PAN data if they have access to both the
  truncated and hashed version of a PAN. Where hashed and truncated
  versions of the same PAN are present in an entity‘s environment,
  additional controls should be in place to ensure that the hashed and
  truncated versions cannot be correlated to reconstruct the original
  PAN.

Which should prevent the attacker from staging an offline brute force attack.

Also, these are the minimum requirements. It states in principle 7 that:

  Requirement 7: Restrict access to cardholder data by business need to
  know

I imagine displaying all 10 allowable digits to customers would fall outside "need to know". Perhaps the last 4 are required to identify which card is which, but most users wouldn't need to know the first 6 except perhaps to be shown what type of card it is.


How could mobile developers prevent bypassing certificate pinning with tools such as SSL Kill Switch?

From the github readme for the iOS SSL Kill Switch project:

  Once installed on a jailbroken device, iOS SSL Kill Switch patches low-level SSL functions within the Secure Transport API

So your question basically boils down to: "How do I prevent my app from being infected with malware on a rooted / jailbroken device?". In short: you don't. This is why you don't root your device!

There are obfuscation tricks you can do to make this harder; for example write your own in-house SSL / TLS library (terrible, horrible idea, don't do this!), and then include this crypto in your compiled program so that there's no dependency on the OS's crypto libraries. Now you're immune to a hack in the OS's crypto layer, but if the attacker is targeting your app specifically then there's nothing to stop them, so you're not preventing an attack like this, just making it more difficult.

Another trick I've heard of is for the app to try to detect if it's running on a rooted device, and refuse to run if it is. That said, if you google "bypass jailbreak detection" you'll see that there is a constant game of whack-a-mole going on between hackers and developers where the hackers are getting increasingly clever at hiding the jailbreak. I don't recommend playing this game.


A DDOS attack by uploading a few hundred large files - whats stopping anybody?

but this happens after the fact

Really? What webserver are you using (you forgot to tell us). Apache, nginx, lighttpd all have options to limit the size of a request (the request is dropped if the client supplies a size greater than the limit in the header or the limit of data is received by the server).

If you want to validate the size before uploading it then you'd have to implement a non-sandboxed java applet.

  This would mean that our network pipes are clogged handling 10GB of data

No - not if you implement QOS based traffic management. This can be tricky to do on the operating system (again you forgot to tell us what this is) - if you are using Apache then have a look at mod_qos or mod_bw

  How do we even detect such an attack

Active monitoring + automated responses - If you're using some flavour of Unix, then ensure your webserver is confiugred to cap the post size and LOG MESSAGES on violation, then set up fail2ban to process those messages.

  Can you turn back requests

Yes - see above. The only caveat is that someone trying to kill your servers may tell fibs in the content-length header (which is optional anyway).


How can I explain the concept of public and private keys without technical jargon?

Note: This answer is aimed at really non-technical people, I have tried to make it understandable by a child, please don't be offended!

Lets say I want to send something to you, but I don't want anyone else to be able to read it. The first thing that comes to mind is encryption! Encryption gives confidentiality, right? It sure does, but there are some problems to address.

Classical, or symmetric encryption requires some kind of shared secret. In the computer world, this is called a key. The problem is, in order to communicate confidentially using symmetric encryption, we both have to know the same key. We have to communicate this key to each other by some secure means before we can use it. It's a chicken-and-egg situation, we need to send the key confidentially in order to have a confidential channel.

One solution would be to meet up somewhere physically, agree on a key (which is just a really big number), and then go our separate ways. With this arrangement, we know we are the only two people who know the key, and we can happily transmit messages to each other using it, in the knowledge that nobody else can read those messages.

This solution does not scale well, and in the world of the internet when we might want to talk securely to a few dozen parties a day, that would be a whole bunch of secret meetings to set up, a whole bunch of keys to keep track of, and a fortune in travel costs.

Enter some really clever mathematicians. Asymmetric cryptography is essentially a smart bit of maths that allows us to use a pair of keys. One key for encryption, and one key for decryption. What's more, it is impossible to generate one key from the other.

Think of it like this; the encryption key is a padlock. You just click it closed, and it locks. The decryption key is like the padlock key.

It works like this; I want to communicate with you securely, but we have never met, and share no secret.

You send me your padlock.
I write my message to you, put it in a box, and lock it with your padlock.
You keep hold of your padlock key at all times, so you are the only person who can unlock the padlock. Once I have locked the box, not even I can open it, because I don't have the key.
Then I send the box to you, safe in the knowledge that you are the only person that can unlock it.

Someone watching our traffic can see you send over your padlock (encryption key). But they can't do anything with that padlock except lock things that only you can open. They can't examine the padlock to figure out how to make a padlock key for it, the mathematics of the system ensure this.

They then see my message to you, locked away with the padlock, but they don't have the padlock key, so they can't do anything with it.


Two Factor Authentication with PIN - Does where/how you enter a PIN matter?

In the process of authentication the user enters a password (something he knows) and an OTP value, which was generated by "somehting he owns" - the token generator.

I think you can change the first compoment "something je knows" in this way, that is provides the same security level in mechanism 1 and mechanism 2.

In my opinion it is important to take a look at the possession, "something he owns".
So the question is, what kind of OTP generator are you using here? What are the attack vectors for this token generator?

Image you have a hardware token generator, then an attacker needs really physical access to the device. (Let us assume, that the secret key was not compromised during delivery of the hardware).

On the other hand, if you are using a software OTP generator like a smartphone app, the possession might be prone to additional attack vectors. I.e. Imagine the storage of the users smartphone being copied by an attackers rogue program.
Then it might be a good idea to use mechanism 1, and use the local smartphone PIN to encrypt the secret in the smartphone storage. This would protect against remote attacks on the smartphone storage - remote attacks on pyhsical hardware or "not possible".

So in my opinion: If you have a real possession factor, one that is not online attackable, you do not need a local PIN.

And: When logging in to the website you do not need Password + PIN + OTP. Two "knowledges" are as good as one knowledge. So simply use Password + OTP.


How does setting Origin to null in a redirected CORS request protect against a confused deputy attack?

That paragraph is tersely written, and the use of "redirects to another resource at a new origin" in the first sentence isn't quite right.

Here's a simple contrived example. Let's say you are malicious, and there is a web application that uses the services of a privileged API via CORS, so the web application's Origin is trusted by the privileged API. And let's say you want to get access to the data behind that privileged API, but your Origin of course is not trusted.

You create a simple useful service that you offer via CORS, and you get the web application to include your service in a page- any page- under its trusted Origin. That page does not need to access the privileged API.

(Of course, once you're in the page of your victim you can do whatever you want, but bear with me.)

If you decide to change your CORS service from issuing a 200 with some data to issue a 3xx to the privileged API- crossing resource domains- this creates a trust problem.

The actual Origin- the page that embedded your resource- will be trusted by the privileged API. But it didn't issue the request, and it may not want to be talking to the privileged API at this particular point in time.

Instead, you issued the redirect, and while you are trusted, in part, by the Origin, you are not trusted by the privileged API. If the browser follows your 3xx and sends along the Origin, you get to illegitimately piggy back on the trust given by the privileged API to the Origin.

What is the browser to do? A reasonable answer is to not follow the 3xx at all, but that would disallow use cases for which trust is not concern. Issuing the request with a "null" Origin allows those use cases, but prevents the exploitation of trust that sending along the original Origin header would allow.


You should not deploy Skein-based software yet.

Internally, Skein is built around a custom block cipher (Threefish) which can be used as a stream cipher or a MAC, but nobody is really looking at the inherent security of Threefish yet, only as how it provides a good hash function, and even for that usage, the verdict has not been reached yet. It takes years of scrutiny to decide that a given algorithm "looks decently secure". A one-size-fits-all primitive has a tremendous appeal, especially for embedded systems with limited space for code, but it will take a few more years before one could officially deem Threefish as secure. Roughly speaking, if Skein is chosen as SHA-3 (by the end of 2012), then it is probable that Threefish will begin to be investigated as an encryption primitive, in which case it could be declared as "seems good" by, say, 2016. You will have to be patient.

Another reason why you should wait a bit is that Skein and/or Threefish may still be subject to modifications. At regular intervals, SHA-3 candidates can be "tweaked" (slight modifications designed in the light of prior analysis). Skein was tweaked for second round of the SHA-3 competition, then tweaked again for third round. Which version is implemented in pyskein ? There's room for interoperability nightmares here.

As for your other questions:

Skein / Threefish does not incorporate any automatic key stretching.
Skein as a stream cipher is a stream cipher, not an authenticated stream cipher. It does only encryption. Skein may also be used to compute authentication (as a MAC) but there may be issues to take into account if you want to use the same key for both usages (i.e. don't do it unless you are sure it is safe, and quite frankly I am not sure).
The "nonce" should be an arbitrary string, not really limited in length. In the general Skein description, the nonce and the message to hash (when hashing) use the same input mechanisms. Skein as a stream cipher is "just" a hash function with a key, no input, but a very long output.

Of course, pyskein may add arbitrary limitations, so I refer you to the pyskein documentation, if it exists at all.


Center for Internet Security Version 6.1 Critical Security Control 16-10

Is there any way to add such user access constraints as day names,
  date range, time of day and access duration to a Windows O/S

Days names and times of day can be controlled using the Logon Hours attribute of Active Directory.  You can set it manually, on one or on a selection of users, or you can use a script to automate the process.  You'll also need to Force logoff when logon hours expire to actually force them off at the end of their time.

As for logon duration, it's possible for you to calculate it from the logs, but not to configure a maximum in Active Directory or Windows.  (That's not completely true.  With Microsoft Live Family accounts, for example, you can impose both time-of-day and duration limitations on your children if they're under 18.  I haven't seen that feature show up in corporate Windows, however, probably due to the lack of children in most corporations.)

  report when attempts are made to use the user account outside these constraints?

You can extract this information from logs (if you're using a SIEM, you should be able to make it alert or report).  For example, Windows Event ID 4625 ("An account failed to log on") entries with Status = 0xC000006F mean "User logon outside authorized hours."


How does Google Analytics prevent fake data attacks against an entity's traffic?

Ultimately separating real data from the fake is almost impossible, but in addition to the measures you listed Google employs blacklists. This problem is likely to never go away.

Review this question for more info.
https://stackoverflow.com/questions/2418609/how-does-google-analytics-prevent-traffic-spoofing#2419115


Which part of a self-signed certificate can be trusted?

Public and private keys are linked in such as way that if two certificates have the same public key, they were created using the same private key.

So if you assume that the private key is indeed kept private, the part you can trust in the certificates to identify the creator is the public key, and by extension the digest of the public key.


User authentication: In HTTP Server vs. in Web Application

The advantage of authenticating at the application is having this done independently of the OS and web server, you are not mixing your implementation layers (i.e. the application's authentication and access controls don't rely on information passed on from another piece of software).
Generally the advice of not authenticating at the web server level is a good one, since there's limited control of granularity and it affects the concept of server side sessions. But it's also a one-sided argument and there could be good reasons to use it. Context is critical.
Personally I find, at face value with the information you shared, I find it a poor decision to essentially break a functional setup and shoehorn a type of solution into multiple applications that may not be running on the most up to date platforms or receiving sufficient amount of maintenance effort. It's both fixing what isn't broken and multiplying effort. If/once it's done you'd probably be in a better position for the future, but getting there will become a problem.


Linux 'add_interrupt_randomness' implementation - low entropy contribution by cycles and jiffies?

They are both processed.
Both cycles and now are mixed into the fast pool in their entirety. See the relevant lines:
fast_pool->pool[0] ^= cycles ^ j_high ^ irq;
fast_pool->pool[1] ^= now ^ c_high;

In order to distribute randomness a bit, the number of CPU cycles* that have occurred since boot are mixed with the high bits of the number of jiffies, and the number of jiffies are mixed in with the high bits of the number of cycles. Even when this is happening, the full number of cycles and jiffies are inserted into the fast pool with the XOR operation. There is no c_low and j_low, but the bits are added.
The fast pool is defined in the random driver as:
struct fast_pool {
    __u32           pool[4];
    unsigned long   last;
    unsigned short  reg_idx;
    unsigned char   count;
};

The fast pool contains an array of four 32-bit values. The cycle counter, stored as cycles_t, may be a 64-bit value as it is defined as an unsigned long, so writing just the cycle counter to one of the pool elements will discard the high bits. This is not ideal, so the high bits are obtained separately and put in their own 32-bit integer which is then added to the pool on its own, in effect preserving the entire 64-bit value despite only being able to mix in 32-bits at a time. As you can see with the following two lines, if the two values already fit in a single 32-bit integer, the (non-existent) high 32 bits are set to 0:
c_high = (sizeof(cycles) > 4) ? cycles >> 32 : 0;
j_high = (sizeof(now) > 4) ? now >> 32 : 0;

The process is thus:

If the variables are larger than 32 bits, save a copy of the high bits, otherwise set the copy to 0.
Mix in the variables with the fast pool, discarding the high bits during integer conversion.
Mix in the saved high bits, in effect "folding" the low and high bits into a single 32-bit integer.

* On some architectures, such as certain versions of MIPS, the cycle counter may not be available.


Is HTTPS required when there's no sensitive data in the site

It sounds like you have plenty of sensitive information on your website!

Even if your site contains no sensitive information, though, implementing HTTPS is a sound decision. Insecure HTTP connections are vulnerable to a man-in-the-middle (MITM) attack, allowing an attacker to impersonate your site with ease. Clients have no way to be sure they're actually connected to your server, rather than someone else's pretending to be yours.

HTTPS provides authentication by allowing clients to verify your server's identity, as well as confidentiality by preventing third parties from snooping on your traffic.


Should operating system passwords be complex if full disk encryption is used that has a complex passphrase?

There are a few reasons why you'd still want complex passwords, though, they're all a little situational.

Local access or theft of your machine while it's on (or in sleep mode) but locked. A bigger problem for laptops or workstations in open offices/public areas, especially if you don't disable normal sleep and go straight to hibernate.
Remote access via password (RDP, SMB, various RPC / remoting systems on Windows; SSH or VNC / Screen Share or similar on others). Obviously not an issue if remote access is disabled, public-key only, or enabled only for specific accounts that do have strong passwords.
Combined with a TPM for defense-in-depth if your FDE key/password is compromised; the thief still wouldn't be able to mount offline attacks without the TPM, and still wouldn't be able to mount online attacks (aside from things like freezing the RAM to extract the master key) without running into the OS anti-brute-forcing protection.
Defense in depth (in the case the FDE is either bypassed via an online attack or similar, or totally compromised) for data encrypted with EFS or DPAPI (including Credential Vault and saved private keys) on Windows, for Keychain on Mac (assuming your Keychain password is different from your FileVault password; by default they're both the same as your login password), and of course for SSH, GPG, and KWallet/Gnome Wallet/etc. keys on Linux (which aren't tied to your login password but should still be secure).


As for the question "Should one use separate SSL certificates for front-end and back-end?", the answer is NO

  Secure Sockets Layer (SSL) certificates, sometimes called digital
  certificates, are used to establish an encrypted connection between a
  browser or user's computer and a server or website. The SSL connection
  protects sensitive data, such as credit card information, exchanged
  during each visit, which is called a session, from being intercepted
  from non-authorized parties.

Why? Because as you said, both are running on the same server.
Although You can use multiple SSL certs on different sub-domains but its usually the BEST to stick to one SSL Certificate per domain.


localhost to localhost ICMP traffic that is suspicious.. any idea of what is creating this?

As per this StackExchange answer, you can find it using lsof by looking for st=07 on a raw socket:

# lsof -n | grep -i st=07
ping      19241            gowenfawr    3u      raw                         0t0     477269 00000000:0001->00000000:0000 st=07
# ps aux | grep 1924[1]
gowenfawr    19241  0.0  0.0   8596   832 pts/0    S+   07:26   0:00 ping localhost
#


What is "play security information update"

This is good.

Google Play Protect periodically scans your device to remove harmful applications.

As all other applications on your phone, it needs to be updated, thus the message on your screenshot.


What can I do if I discover that my password hash has been leaked in pastebin?

The first rule is to clean up your act: use a password manager and have unique, long and random password for EACH and ALL your important services (email, google, etc.) and change all your passwords.

Then check if there are some mysterious transactions made on your accounts (not specifically bank accounts, mind you: anything that could be accessed using the email that was compromised). That should give you a good indication if the possible risk of being breached was realized.

Finally, take each possibly compromised account and think of how it could lead to a continuing issue: could some information extracted from that account be used in the future ? If yes, is there any action you might take to reduce the consequences ? Is the risk you're running worth the price you're going to pay to mitigate it ? If you can't mitigate it, can you ensure it ? Is it even worth insuring ?


Are latency based Proof-of-Work systems capable of preventing DDoS attacks on popular hidden tor services (.onion websites)?

The article you quote applies their latency system on SYN packets, the first step of a TCP handshake. For the attacker, SYN flood attacks are attractive because they work well with IP spoofing: since the attacker does not need to see the response packets from the server (the SYN+ACK), then the attacker can use a fake source address, and thus remain "hidden". None of this really applies to a Tor hidden server, because, by definition, the attacker cannot know the true IP address of the server. Indeed, when accessing a server through Tor, any client talks to it only through several successive routers, and the router which actually talks to the hidden server will not be the attacker's machine (or, at least, so we hope) -- thus, no SYN flood.

(Or, more accurately, an attacker can SYN flood any Tor relay node, but cannot know which relay node is actually his specific target site.)

The principle of latency might still be applied, at a higher level. It exists in the case of emails; this is called Greylisting. Upon first connection, the email sender is being temporarily rejected, and informed that it should try again later on. Only if it comes back after a few minutes (or hours) then the email is accepted as genuine. This assumes that the spammer won't allocate resources to remember the email sending, thus won't come back.

Translated to a Web context, this would take the form of a special HTTP response "come back later" which would include a secret token computed by the server, to be included in the response, so that the server knows that it is "the same client" than previously. Doing that without allocating too much memory on the server can be tricky (encoding dates, counters and a MAC in the token can help). However, a big issue remains: this system needs client cooperation. We cannot rely on the attacker for cooperating...

Latency-based systems work as long as the server can know when a given client is coming back, but also when this is a new client. This must work both ways: a returning client must be able to prove that it is the same client than previously (the "secret token" alluded to above can do that), but it must not be able to masquerade as a whole new client when it is actually a returning client. The privacy features of Tor effectively prevent that. Indeed, if any connection could be unambiguously identified as "new client" or "same client than previously", then client tracking would be too easy.

Thus, we can say that Tor is indeed incompatible with anti-DDoS systems which rely on client tracking, including latency-based system.


What is an excessive amount of SYN requests for port scanning?

You can safely assume that they are looking for whatever they can find. Port scanning is a step in "Information Gathering" which is one of the attack phases. You can't attack unless you know what there is to hit.

"Excessive" is defined by your normal traffic and how much load your systems can handle. For Google.com, "excessive" is defined very differently from your personal site hosted on a VPS.


Managing multiple SSH private keys for a team

Not sure why you're using AWS-created keys.  The "Network & Security / Key Pairs" screen also has an "Import key pair" button, I've successfully used it.

When you add a new team member who might be standing up new images, get his public key, import it.

Keep a copy of your standard "authorized_keys" file, with one or more public key per person, on a webserver or S3 (could be VPN-facing, or secured by a team-shared username and password, if you're trying to keep your team identities confidential.)  Now part of your deploy process is to do

curl -u username:password \
  https://team-server/private/authorized_keys.txt >/home/ec2-user/.ssh/authorized_keys

(Such a command could also be added to the instance user data to run at instance creation.)

To add a new team-member, add his public key to the file, then run that command on all servers.

To remove a team-member, remove his key from the file, then run that command on all servers.


HTTP/S  HTTP/S cross-site requests: what do third-party websites know about where their objects are being referenced from?

It is most browser dependant, but as per RFC, case 2 should not have the Referer header per security reasons. In all other cases, RFC states that it could be included unless the user has configured any privacy setting (like private browsing).

So in cases 1, 3 and 4, ysite would probably get the whole referer xsite.com/page.html and in case 2, it (probably) will not get any information.

For that reason, most CDN, advertisement and/or analytics sites have javascript that allows them to rewrite their links to match the same protocol (http/https) as the refering page.


If a malware/virus can insert from clipboard to a webbrowser form, than can it insert key presses too?

Yes, a virus can do nearly anything it likes, including capturing or simulating key presses and mouse movements.

However some technology tends to make it harder under some conditions. For instance on Windows the Ctrl+Alt+Del key sequence is handled in a very specific way, moreover some application take advantage of Windows' Secure Desktop feature to enter private information like passwords which is precisely designed to keep any other user's processes from interacting with this secure input.

However, since at the end any input is handled by some software, a malware advanced enough which managed to get the highest privilege on your machine (the SYSTEM account) will be in measure to bypass even these protection.


Could the Stack Overflow Dance Dance Authentication April Fool's joke actually work in a real environment?

Any analysis of a human's behaviour has the potential to be used as a form of authentication (keystroke analysis), but there are problems if you attempt to make it a primary authentication factor.

It is far better to use biometric characteristics instead of behaviour as there is less chance for change from attempt to attempt in normal operation. Fingerprints don't change throughout the day, but your enthusiasm while dancing (or typing) can wax and wane depending on your coffee intake.

At best, it might be possible to use behavioural analysis as a "confidence factor" where, if successful, could be used as a part of a second factor for authentication, but failure could not be regarded as a login attempt failure (i.e. not a login failure). Or, in other words, if it works, great, but if it doesn't work, provide the user an alternate authentication challenge.

The UX problems this presents upon failure are a real issue.

So, is it secure? Technically no because for it to be used as a reliable primary authentication method, it would have to be very permissive to allow for normal variations in human behaviour. But it could be used as an augment to provide a confidence factor for another secure authentication method.


What is the real risk from trusted forests / domains?

You can enumerate users

You can enumerate computers

You can query DNS for interesting information

If your domain is now in the search domain of the trusted domain you can use shortname replacements (autodiscovery) etc to try and trick client systems into accessing your resources insecurely and popping into social engineering environments.

This is generally a very bad idea if you're doing this with a third party.  This is why you have Federation systems that use SAML (eg ADFS.)


Expose the source code repository externally or allow VPN access?

Given that you cannot use a dedicated, isolated network for this, I would suggest a modified version of option 1:

Allow access over the web with rigorous security checks.

If possible authorize git users using a cryptographic key (the way github does.) This will make brute forcing attacks very difficult.
Use IP filtering. That is, find out the IP addresses of your contractors and only accept queries from those IP addresses.
Make sure you have good firewall, IDS rules on this box.


Can Chromebooks be affected by malware from an SD Card?

In Chrome OS, all Android apps are running in emulation mode. We can say that due to that, there is some security advantages if we compare it to Android, especially that the device administrator permissions are unavailable on Chrome OS.

But even with that, hackers could always  steal user data, phishing, hijacking CPU power (botnets and cryptomining)...

We can say that Android malware is the same as Chromebook's malware.


Is it possible to disable the fingerprint scanner but not the button it's on?

First of all its a phone with a touchscreen. If you are worried about people stealing your fingerprint by far the easiest way to get it from a smartphone is to lift a print off of the physical device...

Insulation tape should be fine against capacitive sensors (most smartphone fingerprint sensors). If you want to be certain add a layer of copper (or strands of wiring) between the button and the tape (making sure not to leave a fingerprint on the underside of the copper). The sensor measures conductivity at various point. The tape should stop any signal from your finger passing through. Copper would give a differing conducting surface between the tape and reader to ensure all the sensor got was noise.


Is there any Linux distro or kernel patch that wipes a process memory space after the process exits?

Linux zeroes out (i.e. fills with zeros) all pages of memory not when they are released, but when they are given to another process. Thus, no process may obtain data excerpts from another process. However, the pages will retain their old contents until they are reused. I am not aware of any patch which does the zeroing upon page release (Edit: as @user2313067 points out in his answer, the PaX patch offers this option, at a cost which may or may not be a problem on any given system); on a general basis, it would be detrimental to performance because it would fill caches with the zeros, evicting more "useful" data (and that's not counting swap space, which your embedded device probably lacks, but most Linux systems out there have swap).

You can force a sort-of wipeout of data by simply allocating every possible page from another process. Something like this:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int
main(void)
{
    for (;;) {
        void *x = malloc(2000);
        if (x == NULL) {
            break;
        }
        memset(x, 'T', 2000);
    }
    return 0;
}

If you run this program as root, then it grabs all available memory and fills it (in order to force actual allocation), exiting only when there is no memory left. Running as root is needed because the kernel reserves the last few pages to root.

Note that filling memory up triggers OOM conditions, at which point the kernel feels allowed to shoot processes in order to make some room. This happens only when there is no free page left, i.e. the state that you want to achieve (no free page left means that all old pages have been reallocated, and therefore zeroed out). It is a kind of suicide for the OS, because the OOM handling code may kill some essential processes (it tries not to, but hey, these are just heuristics). However, this seems appropriate in your case: if tampering is detected, the device has no choice except honourable disembowelment.

So you just have to launch your critical application in a wrapper (a simple script) which launches the above program when the critical application exits (presumably because of detected tampering).


Dangers of giving away Cell phone details

These scammers are after your money, identity, data, etc. The different things they could do are:

Identity Theft: They could use the information obtained from you to social engineer your cellphone provider to disconnect your mobile service or port your mobile service to another carrier. Once they have access to your number, they could impersonate you and would also have access to your two factor authentication codes (if you've used your number/SMS as your second factor). Based on the type of reconnaissance they've done, they could then gain access to your email, Twitter, iCloud and other accounts.
Data Theft: Based on the information you gave them, they could send targeted malware to your device by sending you SMS messages with links. Opening these links on your mobile browser would result in them being able to exploit a bug in your browser to gain access to your mobile device. They could do this using something like BeEF - The Browser Exploitation Framework Project.
Change your Phone Plan: They could convince the cellphone provider to change your plan, make calls that you would be charged for.

There are many other things that they can do. In summary, if you receive a call from a number not stored within your contacts or from Private Numbers, it's better not to answer the call.

Also be wary of missed calls that are made to your number. Scammers give missed calls from premium numbers to make you call back, after which, you're charged a hefty fee.


How are "security levels" of identities in TeamSpeak 3 implemented?

A TeamSpeak identity is simply an ECC key pair for the NIST curve ECC-256 as generated by the libtomcrypt library, together with a counter value that is a 64-bit unsigned integer.

The security level makes use of a classical Proof-of-work system.

Let PUBLICKEY be the base64-encoded string of the identity's ASN.1 DER encoded public key. Further, let COUNTER be the decimal ASCII-encoding of a 64-bit unsigned integer. Then the security level is defined as follows.

securitylevel := leadingzerobits(sha1(PUBLICKEY || COUNTER))

Consequently, the expected number of counter values that need to be tried to reach security level n is 2^n (under the assumption that SHA-1 is a uniform random function).

Note that in theory, the maximum security level could be 160 (as SHA-1 produces a 160-bit hash). However, the TeamSpeak client seems to set the limit artificially to 128. In practice, this makes no difference, as no one will ever reach a security level over 128 (except another breakthrough in attacking SHA-1 happens).

Source: TSIdentityTool, which is an open source implementation of the identity and security level mechanisms.


John the Riper couldn't crack all the passwoords

Never expect to crack 100% of hashes.

To crack hashes, John the Ripper iteratively tries to input candidate passwords into the hash function and checks if there is a match. If it tries every word in the dictionary you provide it, or if it has exhausted the combinations you have set it to use without having cracked every hash, then naturally it will stop while there is still more remaining. All this means is that the remaining three passwords will need more time to crack, and that you may need to use a larger dictionary. This may mean a few more days, or the passwords may be so secure that it will never manage to crack them. This is to be expected.


Its difficult to tell what limiting network factors might be involved without a full network map, but if you have both operating systems running within Virtualbox on the same host, I would guess that its a virtualbox issue. You've got one os trying to scan the other os's network stack, while both networks are using the same network card. Switching to bridged and using a different connector for each would likely return more accurate results.

To test if the backtrack vm can even communicate with the metasploitable one, I would suggest trying to set up a telnet or ssh connection between the two, or to open up a netcat listener on the metasploitable box and scan it with nmap. Usually a vulnerability scanner reporting nothing at all is indicative of networking issues.


Are there any test cases to ensure the "web-attacks.rules" snort file works correctly?

Usually people use a web application firewall to detect/prevent these attacks.  mod_security is an open source WAF.

Any web application vulnerability scanner should do the trick.  Skipfish and wapiti are both open source web application vulnerability scanners.


Best Firewall Zone Settings for Security Gli-net Routers

Some routers understand zones differently, but I hope you will be able to distinguish:

LAN: Accept | Accept | Reject

WAN: Drop| Accept | Reject

Guest: Reject | Accept | Reject

OVPN: depends on what you want.

The reason for WAN inbound DROP rule is to lower the load in case of an unlikely event of DoS


Is Information Security a Cybersecurity area or the opposite?

Where I work, our team just went through the exercise of how to define ourselves and what we do. I read through your article and while I agree to the point it's getting at, it doesn't want to define an overarching paradigm, because they have vested interest not too.

But I'll give you our context...

While our CISO doesn't agree, we like to refer to ourselves as Cybersecurity Experts.

From the Wiki:

  Cyber- is derived from "cybernetic," which comes from the Greek word
  κυβερνητικός meaning skilled in steering or governing.

Since our primary role is in governing all things related to Security in the organization, this makes sense. Other descriptions (InfoSec, DataSec, etc) are all extensions of this governance.

As an example, the Cyber Security team has developed a policy around who can see NPI (Information Security), who can access NPI (data security), and how to transfer it (Communication Security). The Cyber Security team enforces this by ensuring the Provisioning Team (Information Security) has provided adequate controls per a persons role, the data is stored encrypted, audited, etc byt the DBA's and Server Teams(Data Security) and TLS is setup from the Network Team(Communication Security).

Most of my posts talk about this, but what Security Teams primarily do, is Risk Governance. I think this is where the article goes bad. It's sexy to know about vulnerabilities and exploits, but that's not Security. Any techie can do that with a little googling. It's in how you manage you environment and how it connects where the real definition of security comes in.


Is Domain Logins a potential attack vector?

Basically, Microsoft Active Directory is a database containing encrypted user information.

But anyway, regardless of the format you're using to store this information, someone able to physically enter the server room and steal / harm the server will damage this information and cause business disruption.

MS Active Directory is a robust technology used by many companies, and it will provide an acceptable level of security when it comes to user management, identification, authentication etc. providing it is configured properly and follows the Active Directory Best Practices.

Note that other technologies might do the same job and will provide the same level of security if they are configured properly as well.


Why adclick.g.doubleclick.net listens on all ports

My guess: you modified your hosts file to include 0.0.0.0 adclick.g.doubleclick.net or 127.0.0.1 (same) as a way of preventing webpages (or maybe apps) from accessing that site, likely because you don't like advertising or consider it a privacy violation.

As a result, when tools like netstat etc try to display something that is using address 0.0.0.0 (which is actually the special value INADDR_ANY) or 127.0.0.1 (which is actually the loopback address used for localhost) they end up displaying the bogus name you assigned to that address. Try netstat -n to turn off name translation and see what is actually going on.


How can GNSS spoofing be so easy? Don't the satellites sign their messages?

Ultimately, the answer is that there is no way of preventing jamming and fine spoofing in GPS or a GPS-like system due to the inherent principles of which it operates.

RF systems are always subject to jamming. You can make it more difficult, as modernized GPS does with error correction, higher powers, and multiple frequencies. But you can always overwhelm a receiver with a huge signal.

Encryption in the military code does prevent gross spoofing, where contents of the message are modified. However, it is fundamentally impossible to prevent all spoofing in a 1-way broadcast system.

GPS operates by measuring the relative delay between the signals transmitted by multiple satellites. There is no way to guarantee whether a delay was real, caused by the travel of the signal in space, or if the signal was artificially delayed, say by recording the signals and playing it back slightly later.

Environmental effects, namely the ionosphere and reflections between buildings, naturally do this for us and are major sources of GPS error.

To summarize, there is no way of authenticating a variable time delay by cryptographic means in a 1-way system.


Ransom attacks - can I protect myself by encrypting all my files?

TLDR: Any file encryption does not protect you against Ransom Attack.

We can consider two scenarios:

You encrypt your files with some tools (e.g. encrypted zip),
You have encrypted whole partition (Truecrypt, dm-crypt etc.).

In the first case, even if you have encrypted your files they can be encrypted again by ransomware. And then you won't be able to decrypt them. Bad situation.

In the second case, ransomware lives in the computer's runtime (while you're using it), therefore it has an access to decrypted files on your computer. The disk partition is decrypted on boot up and encrypted again when you shutdown your machine. Again, bad situation.

A file encryption does not protect you against ransomware.

The Cold boot attack is a bit different story and you shouldn't consider it here to not confuse yourself.

I've tried to explain it in the easy way, I hope I helped somehow :)

To protect against ransomware you can (should!) do at least these three things:

Do not visit malicious sites.
Backup important stuff (on a separate, unplugged drive) :)
You can also install some antivirus, EMET etc. The likelihood of being successfully ransom-attacked will for sure decrease.


How protected mode in CPU is really implemented?

There's a bit in a register that indicates whether the CPU is currently in kernel mode or user mode. Program code cannot modify this bit directly: it has to use special instructions that do more than just change this bit. Certain instructions can only be used in kernel mode; attempting to use them in user mode instead triggers a trap.

While the processor is running in kernel mode, it can switch to user mode at any time. But while the processor is running in user mode, there are only a few ways to switch to kernel mode: with the system call instruction, because of an interrupt, or through a trap. In all cases, the processor doesn't just switch to kernel mode, it also jumps to an address in memory which can only be configured by kernel code. This ensures that user mode code cannot execute whatever it wants in kernel mode. User mode can only call a few specific entry points in the kernel code, and the kernel code at these entry points can set up its processing environment carefully and validate its inputs.

All of this would be useless if user code could modify the content of memory that contains kernel code or data. It cannot due to the memory management unit (MMU). One of the functions of the MMU is to limit what memory is accessible at a given time. Memory can be marked as accessible to the kernel only, and switching between kernel mode and user mode may change the access permission table. The MMU configuration can only be modified while running in kernel mode. This way the kernel can configure the memory so that it can access its own code and data, but user code cannot.

The kernel actually maintains one MMU configuration per user process. Before switching to user mode, the kernel modifies the MMU configuration to correspond to the one for the process that will be executing after switching to user mode.

Pretty much any sufficiently advanced processor follows this basic model: not only any PC manufactured in the past 30 years, but also any smartphone and even many embedded devices.

I've simplified a lot of things. In the real world, there can be more than two privilege levels, more processor modes, more aspects of MMU configuration, etc. You have the gist of how it works. If you want to understand kernel code or write your own, you'll need to read about a specific processor architecture in more detail.

“Real mode” is a historic aspect of x86 processors. It hasn't been relevant in the real world for the past couple of decades except in some rare embedded x86 systems and to some people writing bootloaders or running some really old legacy software.


KDC(Key Distribution Center) vs Asymmetric Key Exchange

KDC is suitable for smaller infrastructures where you place explicit trust into each person or node doing encryption. Each time Alice wants to encrypt a message to Bob, she has to ask KDC for a temporary key to use for encryption. The KDC will also need to provide that temporary key to Bob so he can decrypt the message. You don't want to just give Alice Bob's encryption key, as then she would be able to read all encrypted messages sent to Bob (the nature of symmetric encryption is such that the same key both encrypts and decrypts the message).

As you can imagine, this does not scale beyond local infrastructures, nor is very fault-tolerant. If the Internet relied on KDCs in order to do encryption, it would be easy for attackers to DoS them and kill all commerce on the web -- or at least make it unreliable enough not to bother. This is why browsers went with Public Key cryptography and a framework of mutually trusted certificate authorities (CAs). This has its own set of trade-offs. One, you have to trust that the CAs know what they are doing -- a trust they have repeatedly violated. Two, PKI relies on the hope that we'll never find a fast way to factor the product of two very large prime numbers -- a problem not present in symmetric cryptography. If the likes of Grigory Perelman one day find a way to quickly solve that problem, anyone will be able to obtain the private decryption key from the public encryption key. If that happens, we'll be all in big trouble and will have to come up with some other way for two untrusted parties to exchange encryption keys.

So, to answer your question -- cryptographically, KDCs and symmetric keys are stronger than asymmetric public-private keys, as there is no danger that one day some crazy mathematician will find a way to quickly factor products of large primes. On the other hand, KDCs have inherent problems with key distribution, reliability and ongoing trust that can't be easily solved and therefore KDCs are not suitable beyond local installations where such trust is easy to assure.


Why does TLS1.3 use same cipher suite for RSA and ECC key pairs?

TLS Cipher suites define several parameters including key exchange, encryption and hashing and must be agreed between clients and server.
The use of RSA or ECC certificates does require different key exchange parameters (specifically *_RSA vs *_ECDSA). Whilst just about everything else can be the same in a TLS connection, the actual cipher suite definition must be different when connecting with an RSA vs EC certificate.
https://tools.ietf.org/html/rfc8422#section-2
One thing to note is that the naming scheme of TLS 1.3 cipher suites has changed vs TLS 1.2, which means the above may not be obvious.


Wannacry testing in lab - Not getting SMB scan attempts

WannaCry does not have any VM detection features, at least according to all the existing analysis. WannaCry itself also does not launch the EternalBlue SMB exploit; the WannaCry dropper does. If you're just trying to use the unpacked crypter executable, you won't see it attempting to exploit EternalBlue.

The first thing the dropper does is attempt to resolve and connect to a particular domain (later referred to as the "killswitch domain") on port 80. If it succeeds, the malware exits. It is unclear what the purpose of this was in the original malware, but it could either have been an intentional killswitch or a way to avoid analysis on malware honeypot/sandbox platforms that cause every domain lookup and connection to succeed. Security researcher Marcus Hutchins (aka. MalwareTech) registered the domain after seeing it during analysis and discovering that it was available, without really realising the impact of the domain, and that effectively stopped the progression of the malware in the wild.

The domain in question was:

iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea.com

If your VM is able to resolve and connect to the killswitch domain, the malware will simply exit.

Since the dropper uses the InternetOpenUrl API to perform the check, it respects the proxy settings, so you can configure a non-existent proxy in the Internet Explorer settings in order to make the check always fail and make the malware run.


Force download files protected with auth headers

With a recent browser, you can use client-side JavaScript to prompt the user to save an arbitrary blob (including one you just downloaded from the server using XmlHttpRequest 2).  You can even specify a filename.

See: https://github.com/eligrey/FileSaver.js

One caveat is that I believe the data will have to be cached in memory, rather than written to disk incrementally as it is downloaded, as would be done with a normal file download, which may be a problem for a large file.


Which is considered the first Cyber Security incident?

It is difficult to define when the word "computer" started getting traction and it is more difficult for the concept of "computer security".

To my mind, the first incident in computer security is the process that sparked the invention of the modern computer. That was the work of Alan Turing on the machine that broke the enigma encryption.

  The Enigma machine's use of a reliably small key space makes it
  vulnerable to brute force and thus a violation of CWE-326

While the Bombe was not a fully programable electronic computer (Colossus was the first), security was not an issue until the time-sharing paradigm has been introduced in the 60's. That's when authentication and authorisation were introduced because people would not respect their time slot and resources. The first international conference on computer security in London in 1971 was primarily driven by the time-sharing industry and its customers.

This is a timeline of meaningful computer security events.