Firstly; the devices connected to multiple routers not being able to communicate; is most probably due to a configuration problem. It could also be due to the router being too limited in capability that it was not able to perform as you need it to.

However, be it as it is, what you need is traffic limitation for malware on one computer too.

What the malware could do in theory is that it takes over one of the routers too, automatically, then reconfigure it to get connections to the other routers/computers... as router firmware is not exactly the pinnacle of secure software, and the average home user makes next to no software updates ever for a router, it might be very easy.

This is all dependent upon "if" the malware is programmed to do that, and knows vulnerabilities for your router models of course.

What is "sufficient" for you is something we can't know - are you willing to take the risk of getting router-hacking malware, or would you invest time and money to get a more secure router? Only you can decide that.

Regarding the more secure options, there are several business-class device vendors that actually fix security bugs and make updates available regularly, and there also are open systems like OpnSense which can be installed on your own (capable) device (and also are maintained well).

If you're looking for an "if you do this, then you're fine", then I have to disappoint you - even with the best possible security, there is always some risk.

Finally, about autoclave (which normally should be in a separate question): Stop right now. The developer ended work on it about 15 years ago, but the world moved on with newer technologies.

If you want something that is doing the same work (which is not sufficient to completely wipe a hard disk!), install some Linux on an Usb drive, plug it in in the computer you want to wipe, and use dd with /dev/zero on all hard disks.

The problems with this: There are SSDs with wear levelling etc.,
A solution you would like is to use ATAs SecureErase feature. Depending on Bios etc. not entirely straightforward. Then each modern hard disk has areas that can only be accessed with some vendor-specific commands, normally used for storing various metadata and/or being reserve space. Malware data can be there too. And finally, malware doesn't need to be on the hard disk at all.

Making 100% sure that there is no malware, without eg. melting the computer, is just impossible.


What are these long hexadecimal HTTP requests?

The Shannon entropy of this data indicates it is unlikely to be encrypted or compressed. An analysis can be found here. The Shannon entropy is 3.94, which is actually in the range of typical English text (usually between 3.5 and 5).
Converting the hexadecimal text to UTF-8, I got the following: õ...Ú....ÂU üNØA.äzDv.$3.æIu=-K.ÌéÄ³Ì.Ë_D..m¤uÛÿ©h..Ò7µÉA».ÒªgY÷äã.£.".ÍÎ2.~ÌÇï¤.BîÁ...Ã.$¼<y. L
I don't know what this means, but it really looks like a line from a packet capture, as you might see when running tcpdump or similar. I have no idea why your server would be getting sent these.
As far as determining whether you should be concerned, it is possible this is some kind of command and control protocol being used to communicate via your server. Perhaps you can try appending many of these requests together to see if you'll get more meaning when converting the totality of data to UTF. I'd also monitor your outbound network traffic, especially to the source IP behind these requests.
My best guess is this is just noise. Since you're curious however, these are some next steps you can take. Please update if you learn more!


Some hash functions are based on block ciphers like DES. The maximum (effective) input size of these algorithms are limited by the block-size of the internal cipher. See for example:

http://man7.org/linux/man-pages//man3/crypt.3.html

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

There is of course a non-negligible possibility (we are talking about eGov) that the password storage of your particular service is fundamentally flawed.


Development-led security vs administration-led security in a software product?

The dilemma is not specific to security, but security makes it easier to solve (although not in a philosophically satisfactory way).

Consider the Web browser Firefox. It is very self-contained. For instance, it has its own cryptographic layer, with its own storage of private keys and handling of certificates and SSL implementation and list of trust anchors. Similarly, Firefox has its own settings for proxies. On the other hand, both Internet Explorer and Chrome delegate quite a lot to the operating system in those areas. This is a trade-off: that which is delegated to the OS needs not be reimplemented, BUT this brings the OS configuration into the picture and can add constraints.

For instance, when we want to add some smartcard support to the browser, the relevant driver must be installed in the OS (in the Windows world, a "Cryptographic Service Provider") but this is not sufficient for Firefox, which also needs its own driver (a PKCS#11 DLL). The Firefox way then increases complexity and administration costs. On the other hand, if I set a proxy in Chrome, I set it system-wide and it impacts all other applications; whereas with Firefox, I can set it for Firefox only, which is more flexible; e.g. if I want to observe the behaviour of my Web server when connections come from distinct IP, I would like to run several browsers concurrently, some of which using SOCKS proxies -- I cannot do that with Chrome (unless I use VMs), I need Firefox for that.

So the dilemma is mostly about balancing flexibility with complexity. Firefox is an operating system in its own right, which makes it quite portable, but requires specific administration. Now how does security comes into that ? When we say "security", we often think "blame" (by this 'we' I mean 'most managers'). This solves the dilemma: if, as a developer, I have the choice between trusting the OS to do his job, or doing it myself, then I cannot be blamed for choosing the latter, even if it increases costs wildly.

As I said, this is highly unsatisfactory, but the dilemma is solved. It is even socially admitted that a hired developer refuses to do the job altogether if he feels it to be "unsafe". Whereas delegating to the OS, for security matters, is felt as bold and audacious, and somehow risky, and, as a developer, this had better work and never be hinted at introducing security issues, because otherwise the bold developer will become a bold scapegoat. Woe to him who dares not sharing the ambient paranoia !

(The argument above can be turned into an argument for the integration of the browser into the OS, which is what Microsoft does with IE.)


Spear phishing mails are an attack targeted at a specific person or group. Targeting is done by providing subjects or content relevant for this group. he main difference between "normal phishing" and "spear phishing" is that the attack is only send to few people and it is more adapted to these people. This also means that often a  unique or less common exploit is used in the spear phishing which will not be detected by the usual antivirus.

Thus a mail containing a document which uses macros to infect the system is not necessarily a spear phishing attack. It will be a phishing attack if it is one of these widely send mails containing alleged DHL delivery information or invoices. It will be a spear phishing attack if it is only send to the sysadmin and maybe few other people and contains information specific to their person, their work or otherwise interesting information which seduce the sysadmin to open the attached document.


Amazon let me place an order without me ever being asked for 3-D secure password

Security measures like "3D password", CVV, etc. do not exist to protect you the cardholder. Do not assume that someone who lacks them can't use your card number fraudulently. All they do is allow a merchant who chooses to use them as part of their card processing merchant agreement to obtain a lower transaction fee, on the basis that the feature reduce the rate of fraudulent transactions and thus chargebacks.

If anything, these features actually hurt you as the cardholder, as they make it easier for the merchant to "prove" you authorized a transaction and harder for you to dispute it. See my answer to a related question here:

https://money.stackexchange.com/questions/54772/why-does-the-introduction-of-chip-pin-appear-to-be-so-controversial-in-the-uni/54780#54780


Setting up a secure VM and protecting host network

You are taking the wrong approach here. The purpose (the initial true purpose) of a honeypot as defined by Lance Spitzner was to trap someone inside of a system that seemed to be filled with enough goodies that the attacker would waste time there, giving admins enough time to prevent them from doing damage elsewhere, while studying them. The first open source version that I recall was Deception Toolkit (DTK). With that said, a honeypot was never meant to be on an isolated network.

Isolating your network will likely make your honeypot unattractive. On the same token, running it on a corporate network is dangerous. Many attackers have methods of detecting what is, and what isn't a honeypot. Thus, honeypots often trap low level opportunistic attacks. So be advised, running a honeypot on an active corporate network is a bad idea for a hobbyist. So onto your question, and some suggestions.

Isolating your VM- Depending on your host, and your guest, you would want to minimize the visibility of virtualization applications. For example, the network card (vmnet0 is a dead give away), applets, etc. Creating symmetric FW rules blocking TO your network, and FROM your network. That however, is a dead giveway. Next move? Separate VLAN isolated from even seeing your network. Downside? If you were an attacker, and saw an empty network with no connections, would you stay on the system if you originally thought it was a corporate system?

Suggestion - Download and modify "NetInVM" and place your host, and NetInVM in its own VLAN. Now you have even MORE honeypots, and a mini network generating traffic. You are on an isolated network where your switch/router/firewall controls traffic policies to disallow communication to and from your honeypot. (including ARP, BCAST, MCAST, etc) But be advised... Your honeypot needs connections from the world. If an attacker connects to, he/she too, can connect FROM. Imagine the following:

Attacker --> compromised your honeypot
Attacker --> makes outbound connection FROM your honeypot --> C&C server
Attacker --> analyzes the source of WHO connected to his honeypot
Attacker <-> (thinks) <-> "Odd says I am connecting from a Fortune 100 yet no traffic"
Attacker --> goes dark

A honeypot needs to be believable.


How to synchronize a laptop with mobile phone so as to rack the login details of laptop if laptop is not connected to network?

Well Bluetooth implies that you are close enough (within no more than around 30m line-of-sight) to your stolen laptop that you can make a connection. That doesn't seem very robust as an anti-theft process.

The way it is normally done is that the laptop runs code that reports it's IP address regularly to a central location.

If you want to create your own code, it isn't difficult to do with Node.JS or Python and an Internet facing MQTT broker. MQTT is a pubsub service so you can have a simple client on your phone or indeed a monitor service on a server somewhere that will check for IP address changes and alert you. There are many other ways of course to do the same thing.

An IP address is not that reliable a measure of location of course so there are still significant limitations in this approach.

You could further improve things by finding things on you main networks (the ones where your PC will normally be found) that the service can ping to check that it is where it thinks it should be.

UPDATE: If the PC is not connected to a network, certainly Bluetooth would be better than nothing. But it is very unreliable. Having some kind of Bluetooth device permanently on in fixed locations might help (though please update your Q with more details so we can better help), perhaps a Raspberry Pi with a Bluetooth dongle. You certainly can't do that with a mobile phone because the phone will likely turn off BT when on standby (e.g. most of the time) to save battery.

The other issue with BT is that it doesn't cope well with multiple connections. So a fixed BT monitor would work OK maybe for a single PC but not for many.

What you should do is set up a local Wi-Fi network with the PC's connected to it and have a central monitor watching for PC's dropping off. But how do you differentiate between a theft and someone leaving the office?

I suspect you really need something to monitor for when a PC appears on an unknown network and that was the focus of my original answer.


Is Oracle gathering information from my machine when I download Virtualbox or Netbeans?

EdgeSuite (sub-domains of edgesuite.net) is a service of Akamai : http://www.akamai.com.
Many important companies use Akamai & EdgeSuite network capabilities to host files : Sun/Oracle, Apple, Adobe, etc.
Take it as a mirror site with high network capabilities ;)

Does it try to get information about your computer?

If you download products via your browser via HTTP or FTP: the server won't be able to get a lot of informations, only what your browser exhibits (browser's codename, OS name, ...).


Decrypt RSA ciphered TLS 1.2 traffic using client RSA private key (not server)

I'm assuming that [client] is the configuration for the connection between stunnel and the server. In the case cert specifies the optional client certificate which is used to authenticate a TLS client against the server. This certificate is not involved in the key exchange at all and thus cannot be used to decrypt the traffic. Only the server certificate is involved in the RSA key exchange and thus for decrypting the private key of the server certificate needs to be known.


What is the most powerful type of DDOS/DOS attack?

You are probably referring to DoS attacks that are carried out by excessively sending out i.e. flooding some type of packets, consuming all resources of the target. From that perspective the less resources you need to use compared to the resources exhausted on the other end makes the attack more powerful. In reality, this type of DoS is the least powerful.

In the most powerful DoS attacks there must be some vulnerability that can be used for crashing or shutting down an entire software/system with a single carefully crafted packet or request. It's easy to find many such vulnerabilities by listing DoS vulnerabilities and ordering them by severity (score).

Let's take an excellent historical example:

ping -c 1 -p 2B2B2B415448290D 198.51.100.99

The pattern 2B2B2B41544829 is the hex code equivalent of +++ATH0 ASCII string and 0D is a carriage return character. The count -c 1 is here to emphasize that a single packet can be efficient.
The target answers to this ICMP echo request with an echo reply having the same contents.
Some modems treated the +++ as an escape string to enter the command mode (for commands intended for the modem itself), even without the time guard interval (Time Independent Escape Sequence, TIES). This was to avoid licensing Hayes's patent.
These are Hayes command set a.k.a. AT commands, and the H0 hook status "hangs up the phone, ending any call in progress". The target immediately loses Internet connection.

Of course this example is not so useful today, because modems are becoming rare and the problem has been mitigated long before e.g. using different escape sequences. Critical DoS vulnerabilities like those found on the vulnerability database are also fixed on a high priority. Despite that, this is the most powerful type of DoS, as it takes the least amount of own resources having a huge/lethal impact on the target.


Stunnel is SSL and, in SSL, private keys never need to travel. The "SSL ethos" is that X.509 certificates are used to authenticate peers without a pre-distributed shared secret. For example, when you connect your Web browser to https://example.com, the SSL layer recognizes the server certificate and can make sure that it talks to the real "example.com" without needing prior knowledge about that specific site.

Stunnel is out of this model, since it is typically used between two machines that already know each other. This allows lighter models to be used.

By default, stunnel does not validate certificates. This is stated as so in the HOWTO page (in the "How does stunnel check certificates?" section). If you did not change that setting, then it does not matter at all what certificates you use. Of course, not validating certificates leaves the tunnel vulnerable to Man-in-the-Middle attacks. This can still be acceptable, from a security point of view, if the tunnel is meant to convey only an underlying protocol that already includes cryptographic protection; typically, you use stunnel to get through a school/company firewall, but inside you just run some SSH. The stunnel is there only to keep the firewall unwary of the SSHish nature of the communication. In that specific case, not validating certificates is fine. (Well, fine with regards to your security. You are still circumventing your school/company firewall, which is morally and legally questionable.)

Most stunnel guides explain how to configure stunnel in that no-verification mode, and copying the certificate on both client and server is the most expedient way to keep things running.

If you configure stunnel to validate certificates, then:

The client must be able to check that the server's certificate (the certificate is the public part, NOT the private key), which entails either knowing it beforehand, or verifying its signature with regards to a known CA.
When the client has verified that the server's certificate is genuine, it must still check that it is the certificate of the intended server.
If the server requests a certificate from the client, it must similarly be able to verify it, and check that it corresponds to an allowed client.

There is no code in stunnel that compares the client and server certificates with each other. They really live in distinct worlds; the client certificate is validated on the server, the server certificate is validated on the client. Having the same certificate on both systems has no influence whatsoever on the behaviour of either.

In a certificate-check system, if both the client and server use the same certificate, then the client may impersonate the server, and vice versa. If there are only two machines, then this does not matter much. If there are more machines (e.g. two clients to connect on the same server) then this can matter a lot (you do not necessarily want to allow a client to frame another client with a fake server). And, of course, sharing the private key implies that the private key travelled from one machine to the other, which either used a preexisting tunnel (e.g. SSH), or was a risky operation. Private keys should remain private, and the more a private key travels, the less private it becomes.


Can a CA be defeated by MitM in order to deliver a signed certificate to the attacker instead of the legitimate owner?

CAs use various techniques to protect against this, but at the end of the day, an adversary with the capability to do this is likely to succeed.  For example, Let's Encrypt requests the well-known file from multiple networks, so a MITM is more likely at your end than at the CA.

Almost all Domain Validation schemes fall prey to attacks like this:

Email validation based on WHOIS data?  Hijack the WHOIS server, or intercept the email since almost no mail servers use SMTP over TLS with certificate validation.  (They usually ignore certificate errors.)
DNS record validation?  Hijack DNS.  (That happens a lot already.)
SNI validation?  MITM the server (same as HTTP)

As a site owner, monitoring Certificate Transparency logs can help, as can implementing DNSSEC (especially with CAA).


Best way to ensure integrity of encrypted data which is kept in a public place

You can append both the intended recipient, possible a timestamp or counter (see Ángel's comment), and the hash to the original data, and then encrypt. Upon decryption, you can compare the origin, and the original intended recipient, as well as the hash.

This will not prevent other parties from tampering with the encrypted blob before it reaches your server, but it will enable you to verify it when it reaches your server.


Standard for Determining the Anonymity Level of a Proxy

Most common way of determining the proxy is by analyzing the headers such as HTTP_VIA, HTTP_X_FORWARDED_FOR, or HTTP_FORWARDED (which you've already mentioned). At least, almost all web based proxy detection applications such as this and this analyze these headers to detect whether or not the request has came from a proxy. Try visiting those web applications using with an Anonymous proxy (such as Tor) and they wont be able to detect those headers in the request. This is because Tor does not attach typical proxy headers (such as Via or X-Forwarded-For), or in any other way modify HTTP requests or responses.

I don't know about a particular standard, but according to this Wikipedia article, there are 3 basic types of proxies depending on their level of anonymity:

  Fully anonymous proxies - Such proxies do not change request fields and look like real browser. Your real IP is also hidden of
  course. People that administer internet servers will think that you
  are not using any proxies.
  Anonymous proxies - Do not show a real IP but change the request fields, so it is very easy to detect that a proxy is being
  used by    log analysis. You are still anonymous, but some server
  administrators    restrict proxy requests.
  Transparent proxies (not anonymous, simply HTTP) - Change the request fields and they transfer the real IP. Such proxies are not
  applicable for security and privacy while surfing on the web. You can
  use them only for network speed improvement.


Emails wrongly flagged as spam by filter, claiming suspicious URLs

The product may be "Virus Security ZERO" by Sourcenext, a Japanese software company. They have FAQ pages for it that contains the [***Spam***](Suspicious Urls) text.

If you use Google Chrome to view that page, it should detect that it is in Japanese, and offer to translate it to English. The English version of the Sourcenext website is much more basic, and doesn't seem to contain the same FAQ entries.

I haven't checked out how to report false positives, although with Chrome translating the pages, you should be able to do that yourself (or maybe work out how to prevent your emails from triggering the detection).


Fell for phishing scam. Is my gmail account with 2-step verification vulnerable?

Since you didn't enter your second factor code from your phone, and since you didn't say that you received a text requesting the second factor, you should be safe.

However, if you want to be sure that all bases are covered (or if you hadn't enabled 2 factor authentication), there are a few things to check to be sure that you haven't been compromised and that there are no further back doors into your account.

The first thing you should do is click the Account Activity Details link at the bottom of the Gmail webpage. Then check the history list for any unidentified activity. It doesn't show a lot of history (I can only see 8 hours back on my page), so it may not show you all activity from the time you entered the bad credentials but if you see an unknown IP in the list, you'll know that someone is logging on to your account.

At the top of that Account Activity window, there's a link to "Sign out all other web sessions", which you should click to make sure that no other web sessions are signed in.

Additionally, go to your account settings from the drop-down near the top of the page, then go to Accounts and Import, then check your Account Recovery Options to ensure that no one has set up their account as a recovery account.

Then to to Other Google Account Settings and then go to Sign-in & Security. From here, verify that your 2-Step Verification options are set to only go to your phone number -- make sure no one added an alternate phone or generated backup codes. If you see that backup codes were generated and you didn't generate them, then generate a new list to invalidate the old ones. Also, check the App passwords to make sure that no one has generated an App specific password (which allows them to bypass 2 factor authentication), revoke any credentials that you did not create yourself.

Also in the account settings, verify that no one has set up email forwarding to another address. If they forward a copy of your emails to their own address, they can use your account for Phishing responses and/or to reset passwords for sites that use email for password recovery. While you're there, make sure they haven't turned on POP/IMAP access, though that shouldn't help them unless they have changed your authentication options.

If you found that someone had reset any of your authentication options above, then reset your password one more time, but if you've verified that all of the options are exactly as you set them youself, then you should be safe from someone breaking into your account.

If you have reason to believe that someone did access your account illicitly, then you have to worry that they gained access to any of your other accounts that use email to reset the password, for good measure, reset important passwords like for online banking, credit cards, shopping sites that have stored credit card numbers, etc.

Check all folders (including trash and spam) for any password reset emails that the attacker may have received. Also, check your sent folder to see if he used your account to send emails to others. This is not a foolproof check since the attacker may have permanently deleted any traces of his work.


EU GDPR - Data protection requirement standards missing?

In the GDPR regulation (Article 39, on page 7), it says

  Personal data should be processed in a manner that  ensures
  appropriate  security  and  confidentiality of  the  personal data,
  including for  preventing unauthorised access to or use of personal
  data and the equipment used for the processing.

So this is down to the controller. If the controller is not willing to learn and adapt security controls and mechanisms then they may fall short and could result in a breach. The reason why the regulation may not put how to protect the data is that every company is different and will require different security measures. It's also good to follow certifications like Cyber Essentials and ISO 27001 to ensure the correct security controls and procedures are in place.

I'm not too sure on the legal side of being sued, but I suppose if it's in a contract of work stating certain security measures are in place then they are at breach of the contract.


There are numerous options. VMs designed to be hacked (DVWA, metasploitable, etc.), hacking websites where attacks are permitted, or creating your own service.

But don't overlook the obvious: your own router. The login web page is simple, and you know the password. Give it a shot.


You can write a frame for any function call, it doesn't have to be system(). However most exploits will aim for a shell if possible. The fake_ret address is simply where the execution will return to after the system() call. If you just put \x41\x41\x41\x41 there it will segfault. If you point it at exit() it will gracefully exit, or you could point it at a number of pop register followed by a ret to control execution down the stack (ROP).


Is accessing bank account on the internet really secure?

Security is relative,  for instance is accessing a bank in real life very secure?  You might get robbed at gun point.  Your ATM could have a Skimmer to steal the data off your card.

Sure SSL has its problems, the PKI also has its problems,  and  people are working on it.  The EFF is promoting "Sovereign Keys",  which basically prevents countries like Iran from forging a valid certificate for Gmail.  Moxie Marlinspike's proposed solution to rogue CAs is Convergence.

Very few people can full off an attack on SSL,  but when it breaks its really bad.  However,  a MITM attack won't get you shot.  So online banking is a lot more secure than any alternative we currently have.


Why is a very anonymous spammer exhorting me to "not forget about all my tasks"?

This is typical malware/phishing/market spam "discoveries".

Validate recipient email address
Validate sender email address
confirm your email server allow mail relay from same domain origin without authentication
Confirm your email server accept and whitelisted the return path instead of bouncing the message.

113.105.180.234  belongs to ChinaNet Guangdong Province Network netblock.

In fact, it is normal for spam attacker to launch spam discover and attack using cheapest ISP they can find. Spreading the attack from multiple service providers will increase their success rate. In addition, spammer can "cross sell" vulnerable server and email address to others.

Disable open-relay only mean spammer can't use your email server to attack others.  You need another level of security to prevent scammer sending mail by phishing as user insideyour domain(e.g., scanner@example.org ,Jacob.Lamothe@example.org  ), which people will fell into pray and think it is legitimate mail.

Please go through your mail server restriction setting to find out what is the best strategy. Do take note that, before you implement such restriction, you must check out whether there is any internal services(that may not have the authentication abiliites) affect by the restriction. You may need to give explicit internal-IP exception for those services..


When you find the vulnerabilities and hack through the system, you will see various files that contain strings like: token_ssh:. This is what you will have to use there.

Tokens are for you to prove your progress to the lab owners and participate in the contest. It is already won by Beched though.


Can I communicate with a wireless device, without logging in the same LAN?

When somebody connects to a wireless access point, their communication happens only through that access point. If you want to communicate with a member of that network, you must get the access point to route/forward your signals to that device. To do that, you must be part of the network; in other words, to associate and get authenticated by the access point.

So, no, you cannot port-scan the devices inside that network unless you somehow create a network with them (some wireless ad-hoc network) or by exploiting the access point from the Internet (using its public IP address). For the same reason you also can't login to one of the devices using telnet or any other service.

As for spoofing the network, yes it's possible. You just need to use some social engineering, i.e. create another network with the same SSID and trick the others to connect to it. You might also do some trickery like pulling the AP's power plug so the other users will only have your network to connect to.


If my server was compromised, is my database safe?

There are a couple of ways to check the validity of your data. Not finding signs of tampering doesn't mean your data was not compromised because the logs could be compromised as well. Logs should be kept in a different security container.

Check for changes against a backup. Even if the backup is old you could still identify changes to old data.
Check HTTP server logs for requests that would have touched the data.
Check DB server logs for queries that change data in a different way than the web application does. You can eliminate valid queries and identify malicious ones by sorting the queries by type and count.


Is biometric security viable in the long term?

You've asked a lot of questions in one go.

The big factor in your question is when you only use biometrics as an authentication mechanism. Typically, the biometric data is combined with other data (e.g. a password) in order to provide authentication data. In this way, fingerprints are viable because they are not the only thing a person needs.

As for the stolen database of fingerprint hashes, you are protected in that the hashes will be unique for that system. Just as passwords are hashed and salted to be unique, so would your fingerprints. If the database was stolen, then in theory, no one would be able to recreate your fingerprints.

As for changing biology over time, the typical scenario if the biometrics of a person changes (cardiac event, amputation, etc.), is that you simply reregister the info in the system. That's not a big problem. There was one prototype system that a person wore that would characterize the person's cardiac profile constantly over time, so it would slowly adjust as the person aged.

So, yes, just as a standalone password has a place in security, so does biometrics. Yes, there are challenges, but biometrics are a convenient way to bolster authentication security.


Unsecure FTP with Encrypted file and Wireshark leakage

You cannot open a remote file with GPG through FTP. Instead you would need to download the file to the local system and open it there. Because of this the decryption will be done only locally (and will be independent from that way the file arrived on the local system) and thus password for the file will thus stay local too.


Data integrity and authentication of an Arduino using JSON Web Tokens and HMACs

Since this is an embedded device and resources are limited, you can reduce this a bit.

You're already computing the signature of the data, so why not just stick the data in the JWT instead, and compute the JWT signature?

This solves a couple problems. First, the JWT is constantly changing, so the ability to replay it can be significantly reduced. Second, you're sending less data.

You need to do a bit of work on the server side to prevent replays. You can timestamp the JWT if you have a clock available to you and only accept values where the timestamp is greater than the last seen timestamp, or just use an incrementing counter in the JWT (request 1, request 2, request 3, etc.).

Speaking pedantically... at this point it's less of a JWT and more of a generic JWS payload. A JWT has specific requirements for claims inside the body such as issuer, expiration/validity, subject, etc., whereas a JWS is more or less just a chunk of signed JSON.


What information is in a gpg cleartext signature?

Here's an example.

Create a key:

gpg --full-gen-key
...
pub   rsa3072 2017-12-23 [SC]
      9727B646039D8D463EE2394531EA459B1AA5A792
uid                      tester (Delete Me) <tester@tester>
sub   rsa3072 2017-12-23 [E]

Create an empty file:

touch empty

Create a detached signature:

gpg --detach-sign --default-key 9727B646039D8D463EE2394531EA459B1AA5A792 empty
gpg: using "9727B646039D8D463EE2394531EA459B1AA5A792" as default secret key for signing

Examine signature:

gpg --list-packets empty.sig
# off=0 ctb=89 tag=2 hlen=3 plen=435
:signature packet: algo 1, keyid 31EA459B1AA5A792
    version 4, created 1514055133, md5len 0, sigclass 0x00  digest algo 10, begin of digest 05 74
hashed subpkt 33 len 21 (issuer fpr v4 9727B646039D8D463EE2394531EA459B1AA5A792)
hashed subpkt 2 len 4 (sig created 2017-12-23)
subpkt 16 len 8 (issuer key ID 31EA459B1AA5A792)
data: [3072 bits]

UPDATE:

  Where is the message digest?

As can be seen from the output of --list-packets the message digest, in my example, is algorithm 10 and begins with the hexidecimal byte pattern of 05 74.  According to RFC4880 Section 9.4, algorithm 10 is SHA-512.

For this part, we'll need to look at the hexidecimal representation of the signature packet:

00000000:  89 01 b3 04 00 01 0a 00  1d 16 21 04 97 27 b6 46  ..........!..'.F
00000010:  03 9d 8d 46 3e e2 39 45  31 ea 45 9b 1a a5 a7 92  ...F>.9E1.E.....
00000020:  05 02 5a 3e a5 dd 00 0a  09 10 31 ea 45 9b 1a a5  ..Z>......1.E...
*00000030:  a7 92 05 74 0c 00 a7 b5  50 c7 26 98 b9 48 7c df  ...t....P.&..H|.*
00000040:  68 e4 8e 4f 07 82 5a 5f  78 a1 c6 30 93 05 9b dd  h..O..Z_x..0....
00000050:  aa 36 ec 89 72 20 4f 06  75 6e 1b 89 ff 2c 2b d5  .6..r O.un...,+.
00000060:  1a af 73 82 a6 e0 85 50  be 59 8a 05 13 d7 ca 2c  ..s....P.Y.....,
00000070:  cd 61 f0 f1 52 c5 47 c2  f9 f0 cd 69 a9 8c 54 8e  .a..R.G....i..T.
00000080:  79 a6 82 b2 1b 15 c0 cf  96 0a c7 88 a9 6e 54 31  y............nT1
00000090:  3d e0 96 62 14 94 6e aa  6b 7d c4 9c 4b c1 14 c8  =..b..n.k}..K...
000000a0:  bb ce ce 22 44 9c 3b df  64 cd ad f5 71 80 e0 d0  ..."D.;.d...q...
000000b0:  63 71 00 df 74 8e cd 82  bc 94 46 26 42 97 85 af  cq..t.....F&B...
000000c0:  84 ea e7 e7 39 2d 45 70  f0 8e 42 65 a2 57 2b ca  ....9-Ep..Be.W+.
000000d0:  75 95 e1 7e cd 2d ab c0  a5 7f 7a 8a e1 e7 7a 65  u..~.-....z...ze
000000e0:  d2 b1 83 46 e0 0a b3 ac  83 66 f9 45 2a a5 b0 7c  ...F.....f.E*..|
000000f0:  8a 64 d7 28 30 68 ee 2f  8f 3a 1c 1e b9 09 ca 92  .d.(0h./.:......
00000100:  27 85 6e 11 da 0a a0 1d  99 b5 e5 04 66 cf 2d 0b  '.n.........f.-.
00000110:  22 57 5d ab 56 70 75 28  81 06 a9 ba 06 92 8d 89  "W].Vpu(........
00000120:  f3 fa 3f 11 45 9e 9c 58  28 a2 6d 54 45 86 a8 19  ..?.E..X(.mTE...
00000130:  5d b4 b3 50 ee c0 ca d3  16 8c 45 be 9d fa b2 40  ]..P......E....@
00000140:  dc c2 1e 0d c1 a8 48 e5  80 61 d8 b9 b6 54 96 78  ......H..a...T.x
00000150:  6b 60 83 ed 63 20 64 6c  ee eb 33 b1 ee fd f1 34  k`..c dl..3....4
00000160:  ab c8 c7 46 1b 20 c8 1e  b6 70 2a c2 2c b4 4c c4  ...F. ...p*.,.L.
00000170:  5d 58 a3 16 e2 73 19 c1  35 6c da 4f dc 67 fa 25  ]X...s..5l.O.g.%
00000180:  1a 99 31 6a 69 21 c5 ca  f1 d7 24 d7 d1 51 ff bb  ..1ji!....$..Q..
00000190:  34 fe a8 b9 fd 2c 4a 68  26 44 cb df 8f 61 7a 24  4....,Jh&D...az$
000001a0:  13 4f 63 26 c5 41 6a 19  7b 9b 24 3d 5a 5c fd 62  .Oc&.Aj.{.$=Z\.b
000001b0:  7a 39 37 1f 5f bd -- --  -- -- -- -- -- -- -- --  z97._.----------

You can see that this byte pattern occurs on the highlighted line.  Since the hash type is known to be SHA-512, the length must be 64 bytes. So, in my example, the message digest is:

05740c00a7b550c72698b9487cdf68e48e4f07825a5f78a1c63093059bddaa36ec8972204f06756e1b89ff2c2bd51aaf7382a6e08550be598a0513d7ca2ccd61

It's important to note that a PGP signature message hash is not only a hash of the signed file or text.  There are several variables including the time of signature which are hashed together.  So, the hash of the file or text is not retrievable from the signature.

It's easy to demonstrate that the message hash changes.... simply create two signatures separated by a few moments in time.

$gpg --list-packets empty1.sig
# off=0 ctb=89 tag=2 hlen=3 plen=435
:signature packet: algo 1, keyid 31EA459B1AA5A792
    version 4, created 1514138633, md5len 0, sigclass 0x00
        digest algo 10, begin of digest b3 66
    hashed subpkt 33 len 21 (issuer fpr v4 9727B646039D8D463EE2394531EA459B1AA5A792)
    hashed subpkt 2 len 4 (sig created 2017-12-24)
    subpkt 16 len 8 (issuer key ID 31EA459B1AA5A792)
    data: [3070 bits]

$ gpg --list-packets empty2.sig
# off=0 ctb=89 tag=2 hlen=3 plen=435
:signature packet: algo 1, keyid 31EA459B1AA5A792
    version 4, created 1514138639, md5len 0, sigclass 0x00
    digest algo 10, begin of digest 04 0c
    hashed subpkt 33 len 21 (issuer fpr v4 9727B646039D8D463EE2394531EA459B1AA5A792)
    hashed subpkt 2 len 4 (sig created 2017-12-24)
    subpkt 16 len 8 (issuer key ID 31EA459B1AA5A792)
    data: [3069 bits]

You can clearly see that the message hash has changed, since the two beginning bytes have changed.  So, even though the signed document is the same and the keys are the same, the signatures are not identical.


How can I analyze password recovery tokens?

If you do not have access to the source code, you will have to make multiple attempts to see if there are any patterns in the token generation. If it is a basic incrementor, this may be easy to defeat. You can take the length of the token into account as well.

Here are some OWASP guides on the topic, which may be of use:

Testing for weak password change or reset functionalities (OWASP-AT-011)
Testing for Vulnerable Remember Password and Pwd Reset (OWASP-AT-006)
OWASP-Security101 Password Reset Options

These will help you with the testing part, but you may want to open a question on the cryto or math SE on how you would actually go about pattern prediction.


How does processor architecture affect password hashing speed?

ARM processors are a 32-bit architecture, and are relatively inefficient at doing 64-bit arithmetic operations: when they must compute a 64-bit addition, they must do so with two 32-bit additions and some carry propagation. This is somehow equivalent to x86 used in 32-bit mode (except that recent enough x86 have access to SSE2 opcodes, which offer computations on 64-bit integers, even in 32-bit mode). All recent x86 can run in 64-bit mode (if the operating system allows it), which makes them much faster at computing hash functions which rely on 64-bit arithmetic operations, the prime example being SHA-512. On a 32-bit hash function like SHA-256, ARM and x86 cores will be "comparable".

An additional twist of ARM is that it has several instruction sets; the original ARM used 32-bit opcodes, while newer versions allow for the "Thumb" instruction set which has smaller, but less powerful opcodes. "Thumb" has been then extended into "Thumb-2", with a mixture of 16-bit and 32-bit opcodes. The newest ARM cores know only Thumb-2. "Thumb-2" code is supposed to be almost as efficient as the original ARM code, while being noticeably more compact. But a lot can hide in a word such as "almost".

For bcrypt, what matters is the availability of about 4 kB of "fast RAM". Almost all ARM and x86 cores you will encounter have L1 caches which are larger than that (to get a cache-less ARM, you have to look at 33 MHz ARM7TDMI or similar systems), so, then again, ARM and x86 will be comparable.

For scrypt, the situation is mixed. Scrypt uses an internal hash function to compute seemingly random accesses in a large RAM buffer, so this is a race between the time to compute the hash function on a small input, and the latency of the main RAM. Main RAM latency does not scale (and a "faster" bus means more bandwidth, not less latency). For a small ARM-based system like the Raspberry PI, the hash function will be the bottleneck, especially if it is SHA-512. For bigger multicore x86, the memory latency will make the whole thing slow. The x86 will not give speedups proportionate with its larger price; especially if using CPU with 6 or 8 cores: there will be too much contention on the shared memory bus.

That being said, the question is about economics: what architecture choice will yield the most hashes per second, for a given budget ? This includes the cost of hardware, but also the energy, which, in the long term, dominates (you pay the hardware once, but you must feed it with electricity all year long). Energy costs must include cooling systems, which are not negligible in big computing farms. ARM processors are reputed to use less energy (it has long been their selling point, and that's why smartphones use ARM processors nowadays).

So the ARM architecture should be, on average and for large clusters, a better choice for password cracking, except when dealing with a CPU-bound hashing process (like PBKDF2) which relies on a 64-bit hash function (e.g. SHA-512), in which case an x86 CPU (in 64-bit mode) will be a better deal. This will change with the advent of 64-bit ARM processors.

For an amateur who does not build a cluster beyond what fits in his room, and must use off-the-shelf hardware, these issues will be dwarfed by those of availability and market effects. You do not buy a lone x86 CPU; you need a motherboard and other things around it; ultimately, you buy a PC. The cost of the CPU will be a small proportion of the total hardware cost. Similarly, you do not buy an ARM, but a Raspberry PI. Therefore, to get a correct estimate, you must perform benchmarks. For raw hash functions, I suggest using sphlib, a library of implementations of various hash functions (including SHA-256 and SHA-512), written in C; it comes with a benchmarking tool. For bcrypt and scrypt, peruse the reference implementations.

(As a gut feeling, I expect a draw. The Raspberry PI cluster will, of course, totally win against the x86 cluster if you take into account the "fun factor".)


Storing privacy sensitive data in a local application

We've been getting an increase in questions like this on this site: standalone workstations processing sensitive data.

You want to be able to gain the benefits of a networked solution but you can't because everything needs to be local. There is a way around this: Docker.

Using Docker, you can create a network and host the elements that you need to secure on different containers. These containers can only be accessed from the docker command or by the exposed ports on the container. This becomes an attractive solution to separate an authentication database.

Securing the ports should be simple enough, but securing the docker command might be a trick, depending on how your workstations are set up and what permissions they have (local Admin?). If they are not local admins, you can use the Access Authorization Plugin.

This way, you can gain all the benefits from a MVC architecture, but on a self-contained, disconnected workstation.

This is not a perfect solution, and Docker is still trying to "find itself", but it is a potential solution depending on your requirements.


How can I protect content distributed on a linux virtual machine?

Have a good read of this question on how effective DRM controls are.

The summary is that no - if you give the code to the user, you can't control it effectively. So one option is to never give them your code:

Can you use a terminal/Citrix type solution to just allow them the experience of using your code? If so, that is the route I would recommend in your circumstances.

Of course, a possible drawback is poor user experience if they do not have sufficient bandwidth.


Is my phone carrier monitoring my traffic?

Your carrier certainly sees the target IP address of the packets that you are asking them to transmit. The carrier's job is to, indeed, carry your packets from your phone to the base station, and, from that base station, to route it to the nearest infrastructure link so that it may reach its ultimate destination. In your case, all the packets that you send are tagged with your VPN server's IP address.

If the carrier did not know the destination IP address, networking would simply not work at all. Therefore, it is perfectly normal that the carrier knows that you are talking to some address in Europe. It is part of their duties. Of course, by the magic of VPN, your server's IP address is all that the carrier can see; the true destination address (beyond the VPN) is hidden from them.

Inspection of destination addresses is an integral part of how routers work -- and your carrier is, by definition, your first outgoing router. The carrier will also keep a tally of all the packet sizes, in order to charge you if you go beyond your allocated quota. For cleartext traffic (HTTP), many carriers will also try to operate transparent proxies so that they may make some savings on their own bandwidth; your VPN prevents such proxies from operating. And, of course, your phone tends to use the DNS server provided by the carrier, so any name resolution will go through their hands (again, in your case, they will see the name resolution for your VPN server name, but subsequent name resolutions should be forwarded to your VPN server and won't be seen by the carrier).

Whether the carrier infers from such traffic that you would be interested in options for Europe-based roaming is another question. It is perfectly possible that the text message is purely coincidental. After all, my carrier sends me text messages offering discount prices for hockey and football match tickets, and roaming packages for central America, which are of no interest to me.


This way you escape from a double-quoted attribute (") and close the previous tag (>) before opening a script tag that contains your payload. It's one of the most basic XSS patterns.

Example:

<input type="text" value="$XSS">

With your sequence it becomes:

<input type="text" value=""><script>alert(document.cookie)</script>">
 ^- a completed tag                  ^- payload           garbage -^

Note that your vector only works if HTML entities aren't filtered.

So if you can't escape from that attribute, it's XSS-safe. This doesn't trigger:

<input type="text" value="<script>alert(document.cookie)</script>">

You can see the same idea with XSS inside Javascript (e.g. '); to end a string and a function call) or with SQL injections. The first characters of an injection sequence often have the purpose of escaping from the current context.

As for @Mindwin's obligatory SQL injection xkcd strip, I freehand-circled the part I'm referring to:


Is decryption using Java+JSF safer than using JavaScript?

JSF works server side(it renders html/js).... so anything you decrypt in JSF is send out as html/js to the client's web browser (no additional security there).

If you want client side decryption use applets, or thick clients to do the work, and use TLS as transport layer. Any other js decryption thing will not work, and it's a waste of time and money. Of course applets and thick clients are not totally secure either but they can be more of a challenge than js.


What is the best way to get missing information used for risk analysis

You must refere to you immediate manager, and explain him that security is a cost/benefit question. Like in real life: you put a simple lock on your garden shed, a strong door and better knob for hour house and you put you best values in a safe.

You would not use a bank safe to store lawn seeds, but you should not put values in a garden shed. Information security is not different. If you are not sure that doors and windows are all correctly closed you can always start there: identify common and simple security good practices that are not in use in your company and have them applied. But to go further, you must know what is vital for the company and need higher protection.

Real life analogy is often easier to understand for senior managers that are not IT specialists. Do not try to guess yourself, and do not try to steal information form other services, just use the hierarchical path and let the right people take their own responsabilities.


There are almost certainly vulnerabilities in the modem firmware, because firmware is no more secure than other lightly-tested software.)

Odds are very good that the card could engage in DMA attacks if it were exploited, and the odds of a random card like this being exploited and the malware being linux-aware both seem relatively small, unless you come to the attention of nation-state sorts of attackers.

This paper says

  PCI Express peripherals are able, through DMA requests, to access other peripheral memory and the main RAM, even in the kernel memory regions, without any control of the processor. This raises a major security concerns if the peripheral is controlled by an attacker. To mitigate this threat, Intel has integrated the IOMMU hardware component, to filter PCI Express messages.

and goes onto explain that there's contention over performance.  It's likely that the configuration of the IOMMU is not robustly tested.


Android with GAPPS, will Google know my IP even if I use a VPN?

Yes they will, if they care to.

Thanks to the total control on the device, they will know your devices innermost secrets and any of your secrets that you store on your device. The only possible exception is what happens in the baseband code (most baseband code is, I think, not part of Android). VPN functionality is outside baseband code.

Given Google's business model, I would imagine that they would care to (if not now, at some point).

When we choose a device and an OS, we implicitly "trust" the vendors of the device, key device-components, the OS and key OS-components.

Aside: It's not something I care to ruminate about since it rarely ever boosts my spirits. :)


Can you exploit an XSS vulnerability on one page to run code on another page?

The attacker could add some onclick event attribute on the different link of the page.
When the user click on a link, he'll think he got a simple disconnection bug, instead of that, you're onclick event loaded a fake connection page. But, you're still on the domain and you can even manipulate the url with history.pushState(); as an example.


Ways to store keys

On a scale from Least Secure/Easiest to Most Secure/Hardest:

Least secure / easiest

Store the keys in plaintext

This is the easiest way, but anyone with access rights to the file can read the key out.
Store the keys in the system keychain

This stops other users from accessing the file, but depending on how the keychain is setup there are usually not many defences against malware that runs as the current user.
Store the keys in an encrypted file

This is more secure, but it requires the user to enter a password on each load, and the key will need to be in memory for at least long enough for it to be used, during this time it can be stolen
Store the keys in hardware

This is the most secure option, but it requires additional hardware, and if a presence check is not included then malware can talk to the hardware to perform key operations, even if it cannot extract the key.

Most secure / hardest


Use of automated security testing tools in the industry

There are many tools, and a few standards, but no standardized tools and a lot of the tools are expensive.

To minimize risk you basically have to teach your team how to code and deploy securely, conduct security tests frequently, and frequently update your security infrastructure at a very fast cyclical pace.

This can get expensive to do (time or money-wise) so lots of people simply don't do it or they only do a little bit.

The constant "rush to market" isn't helping matters. The current business trend is on speed to deliver an incomplete product rather than building for long-term quality. So inevitably cuts are made and some of the cuts are in security. This is unfortunate because in most cases the cost to re-engineer a product so it has security is MUCH more than it would have been to design security into it from the beginning.


Segmenting Network: Zone location of a multipurpose NAS

When communicating between different zones consider the sum of:

It is best when a high-security device initiates the connection to the lower-security device. So a high-security device doesn't listen to connections passively, but actively controls when and who it communicates to.
Pass the needed protocols (ports) and block the rest, both ways.
Pass the needed IP addresses and block the rest, both ways.
Pass during specific hours, block the remaining time.
Use a proxy if it can aid the authentication/authorization/auditing. (NAS usually implements these sufficiently, so probably not needed.)

In your situation, when you cannot afford to implement points 1+2+3+4+5, it's still better to say implement points 2+3+4 than nothing. It's low cost (as you've already decided you will segment the network) and it does provide some added security.


The Spring Security framework recommends against using double-submit cookies to prevent CSRF. Is their concern legitimate?

This issue was specific in nature, and has since been patched out of Ruby. Flash was more of an example of how one can exploit this issue with a browser plugin, a good example too given it's probably one of the most common plugins, but the actual flaw was in Ruby.

We are also talking way edge case that an attacker could pull this off.

There is really nothing to see here unless you are playing with unpatched versions Ruby.


Yes, LTE uses bi-directional authentication.

From LTE Quick Reference:


Security Best Practices - firewall Outgoing traffic vs incoming

No. Incoming ports should only be whitelisted when the computer is intentionally providing a service to the outside world (e.g. web server, RDP, etc.).
Yes, inspecting the traffic is the only way unless you already have an exhaustive list of software running on the machine and know which ports it relies on. However, this is generally not necessary for home users and extremely difficult to do correctly. If you are the user, it's far easier to educate yourself about avoiding malware. If you have other, less technical, people in the house, you may want to go the software firewall (e.g. ZoneAlarm) route and set it up to block everything by default (perhaps even require a password to whitelist, if that feature is offered).
There are knowledge-base articles, but they may not be 100% lists. In any case, please refer to #2 before going this route.


I connected to a suspicious public wifi using my phone. Is it possible that my phone was hacked?

Is it physically possible? Yes. Is it even remotely likely? No. There are two primary ways to attack someone's device (mobile or otherwise) over an attacker-controlled network, such has WiFi:

Injecting malware - When you are connected to a malicious hotspot, there is the risk that files you download are intercepted and modified. If you are downloading a program for example, a malicious hotspot could replace it with malware. Likewise if you are willingly sending sensitive personal information to a website, it risks interception. For this to be an issue, you have to actually use the network, not just be passively connected to it. You said you did not.
Exploiting the protocol - Connecting to WiFi involves several complex protocols, including the IEEE 802.11 standard (WiFi itself) and DHCP. Any bugs in the implementation of these protocols carries with it the risk of being exploited. If the attacker is exploiting the protocols, then merely connecting to the network (or in some cases, simply being in range of it) is sufficient to compromise your device. Some applications also automatically connect to the network as soon as you connect (for software updates, notifications, sync, etc). If these applications are vulnerable or outdated, it may be possible to exploit those as well. These are advanced attacks and are unlikely to occur, especially if your device is kept up-to-date.

So, what should you do? Despite what some other answers are saying, you do not need to do anything as drastic as a factory reset (note that an advanced attacker can still maintain a compromise despite having done a factory reset). Just set your device to only connect to trusted hotspots, and make sure the hotspots you are using are trusted and encrypted with WPA2.


What is being described is a protection against some classes of known-plaintext attack.  Up until the 1960s or so, most ciphers were vulnerable to these (eg. many of the attacks on the Enigma cipher were based on knowing or guessing part of the plaintext).  Modern ciphers are effectively immune to this: knowing that the AES-encrypted message is "Attack at dawn" provides no help in figuring out what the key is.

Using synonyms, typos, and alternate spellings won't help defeat keyword surveillance.  The system is automated and adding keywords is cheap.


Is this accidental incident considered hacking(illegal)?

Legal matters depend a lot of jurisdiction, so it is quite hard to come up with a single answer. However, in most jurisdictions:

Intent matters. It is hacking if you are willingly trying to bypass security measures or obtain access rights that you know you should not have.
A college with a WiFi access point to which you are connected should have a usage policy to which you more or less explicitly agreed to comply when you connected. These rules should be the first document you should have a look at, because they will tell you what the access point owner considers to be acceptable usage and what is not. This does not necessarily matches what is allowed by Law, but it may tell you what may trigger retaliatory action from the owner.

net statistics on Windows systems is a pretty basic tool which cannot reveal really confidential data, but, just like any other tool, it may help in pursuing nefarious goals. Knifes are not illegal, but can help in killing people; so if you have a knife and wave it around threateningly then security guards may find it fit to shoot you. Similarly, a simple net statistics attempt should not be enough to incriminate you; however, really paranoid sysadmins may take it as a hint that your are up to something nasty, and come down on you. You would probably not be ultimately declared guilty by a court of law (I make no promise here, but that's really improbable), but in the short term this might degrade the state of your relationship with the college sysadmin team, and thus hinder your research efforts. If in doubt, abstain.

In practice I doubt anybody actually noticed the effect of your command.


Is there more of a security risk by providing an email when creating a new account?

Neil has good points. I would like to add some more thoughts.

First: 2FA is a more generic term. Your smartcard, fingerprint scanner and iris scan also add a 2nd factor to 2FA. What you are talking of here is 2FA with OTP, one time passwords. And again with OTP there are many possibilities.

OTP possibilities

There is this cheap way of sending SMS or the cheap way of using your smartphone as your OTP generator. The OTPs are nowadays (there are still some like RSA and Vasco who refuse to adapt) according to RFC4226 or RFC6238. In both cases your device and the backend (site) have the same symmetric key. The key and some kind of moving factor like the keypress (RFC4226) or the time (RFC6238) are combined into an HMAC-SHAxxx algorithm. Using SMS is a bad idea as you saw during the last weeks but also using the Google Authenticator has its disadvantages.

But there are also hardware devices of many different vendors. Google and Facebook will not use those naturally. But sites or portals with some kind of defined or restricted userbase might use such devices. The Yubikey can even be initialized, so that the vendor does not know the symmetric key.

Losing an authentication factor

A user can lose or forget an authentication factor. Either forgetting his password or loosing his possession factor. If you have no workflows installed so that the use either may reset his password or revoke and reenroll a possession factor, than of course the user cannot login anymore. Never again. ;-)

You are right and Neil point with the credit bureaus. The challenge indeed is, to define a secure workflow to reset the password and reenroll a new hardware-token or register a new smartphone. This is why there are management systems for 2FA like these of classical vendors like Safenet Authentication Manager but also open source solutions like privacyIDEA (Disclaimer: I am working on the second one.)
These management systems already provide workflows to revoke or delete possession factors and verify the identity.

Forgetting password

As far as losing the password is concerned, the email reset functionality is IMHO legit. The user can reset one forgotten knowledge factor with hopefully another good knowledge factor (the password of his email account).

Of course the problem arises when the user uses email on his smartphone (with cached password) and the Google Authenticator. Loosing the smartphone will compromise both factors! As the finder (or thief) get the possession factor and can reset the knowledge factor!

But it is also difficult to avoid the user writing his password on a sticky note under his keyboard.

Losing possession factor

The user loses his smartphone. Either with SMS or Google Authenticator. Or his hardware token. What will happen?
First the user has to notify the administrator/site, that he lost his possession factor. The site will lock or revoke this factor, so that it can not be used anymore.

Now it very much depends on how you setup the process. Never send a QR code for the google authenticator via email to the user. In this case your 2FA would be reduced to 1FA as you already realized. The attacker could request a password reset and a smartphone reset on the same (hacked) email address.

The company/site should choose a good process. A simple way is that you can work with emergency codes like the PAM module of the Google Authenticator. Print 5 one time passwords as emergency possession factor. These can be stored "save" offline. If the smartphone is lost, use these to login.

The above mentioned management software can assign several factors to one user. E.g. if the user normally uses a dedicated hardware token to authenticate, he could also have smartphone receiving text messages and only use this second factor to reenroll a hardware token.

Or - not very sexy for Google and Co - the site can send a new authentication device or a new QR Code or some tricky registration codes for registering a new mobile phone for text messages to the postal address of the user.

Bottom line

The sense of 2FA is to raise the hurdle for the attacker. Classical attackers are good in online-software-attacks. They know how to attack passwords on a large scale. This is why text messages or the enrollment process of a google Authenticator are problematic. These are in the same realm of the skill profile of the attacker.

An now you see, why using credit bureaus or postal letters is attractive, since the attacker does not like going to the post office and it just does not scale.


Is there guidance that says all sessions to be logged off when a user changes their password?

OWASP cover this in the top 10 (2010) under "Broken Authentication and Session Management".  The closest statement probably is that it mentions that sessions should be regenerated upon successful authentication of privilege change coupled with Session Timeout session fixation attack prevention.  That's about as close to a standard as you will get.

Other standards such as ISF SOGP etc are too high level to cover this.


As far as I'm aware there is no universal naming convention, only vendor-specific conventions.

For instance:

McAfee: http://home.mcafee.com/VirusInfo/Glossary.aspx
Symantec: http://www.symantec.com/security_response/virusnaming.jsp
Sophos: http://www.facebook.com/note.php?note_id=13314014671

Each vendor has their own particular convention, but a lot of them to overlap.


Do firewall rules have to be symmetric? That is, does a firewall have to block a particular traffic type both inbound and outbound

I believe you have some terminology mistakes in your question, but I still think I can answer it. To answer your question I'll explain both common types of firewalls, stateful and stateless. Both types of firewalls compare packets against their rulesets. Both work from a set of data often referred as a tuple, which typically includes Source IP, Destination IP, Source Port and Destination Port. There are some important differences I'm going to outline below.

Stateful firewalls maintain a table of connections. This means that once a connection is established, traffic that matches that session is allowed through the firewall. For example, if you created a rule that allowed port 80 from the internet to a system behind the firewall, the packet the server sent back as part of the TCP handshake would be allowed. Since a stateful firewall is aware of TCP state it is capable of filtering packets with invalid TCP header information.

Stateless firewalls are limited in their filtering capabilities compared to a stateful firewall, but generally are much faster because of their simpler rule processing logic. Each direction of a connection must be explicitly allowed since no state is saved and each packet is checked against the firewall rules each time. For example, if you created a rule that allowed port 80 from the internet to a system behind the firewall, the packet would be allowed as before. However, without a corresponding rule for the packet from the server back to the client, the response packet would be dropped. These firewalls are not generally able to filter packets with invalid TCP header information.


How to make data in hard disk unrecoverable on linux

Be careful with the word "unrecoverable".
It depends what level of "unrecoverable" you are going for. If you want to stop a casual computer user from reading your data from a live-boot OS, then things like shred, dd, dban will do the trick.
If, however, you are worried about someone flashing the firmware of your drive, or removing the platters and putting them into a specialized data recovery machine, then software alone will not cut it. The only 100% reliable way to "make data in hard disk unrecoverable" is this:

The main reasons for this is are 1) because of disk firmware declaring a bad sector and leaving data on the disk, flagged as inaccessible. I have heard rumours that malicious HDD firmware has been know to search for sensitive-looking data on disk, and flag it as "corrupt" for future recovery by an analyst. And 2) wear leveling on SSD / flash memory drives, where the disk firmware will spread writes around the physical disk in order to prolong the lifetime of each individual sector. I have heard rumours that SSD drives ship with between 25% and 100% extra hidden space (depending on how expensive the drive was) for use by the bad sector / wear leveling algorithms. Both of these hard drive "features" mean that even if the operating system believes it has overwritten 100% of the drive volume, there may be extra copies of your data lurking in hidden areas.
For these reasons, software by itself it not enough to ensure proper erasure, you need some hardware support. Some newer (S)ATA drives provide a Secure Erase command which will reset all sectors (from Wikipedia):

"Secure erase" is a utility built into modern ATA hard drives that overwrites all data on a disk, including remapped (error) sectors.

If your hard drive supports this, and the software you use takes advantage of it, then this is probably reasonably good. However, it's not clear that all disk manufacturers implement this / implement this properly (esp. on SSD's which cut corners to prolong life).
Bottom Line:
On traditional magnetic drives, secure erasure software will probably erase your data properly, but without doing some research into your specific hard drive model, you can't be 100% sure. With SSD / flash / hybrid drives things are even less reliable due to their use of wear leveling. If you want to be properly tin-foil-hatty, then you should distrust any drive - unless you installed the firmware yourself - and either physically shred it. Additionally, using full disk encryption adds another layer of protection, but needs to be enabled from the start.
Related Security.SE Questions:
Secure cleaning of deleted files
How can I reliably erase all information on a hard drive?
Safely remove original file after encryption


This request tries to contact something located at the URL /shell and which takes as parameter a set of shell commands to execute.

While the shell commands to execute may seem obfuscated at first, most chances are that actually they are not. Shell commands may often contain characters which have a special meaning in HTTP URLs, so to keep the commands from being corrupted by either the HTTP client or server the easiest solution is simply to HTTP encode it completely (this is less a matter of obfuscation than the fact that the attacker most likely don't care about the URL readability).

Regarding this /shell URL which (fortunately!) was not found on your server, there are two main possibilities:

This may be the name of a resource specific to the service targeted by the attacker. The name of the file that this commands tries to download seems to indicate it is expecting an ARM device, so the attacker may be a bot scanning the Internet for a specific vulnerable embedded device where this /shell URL is present and enabled by default (for instance a debug feature left enabled by a manufacturer. Bad things happens...).
Another possibility is that this request is not the first step of the attack. The attacker may already have taken one or several step(s) before this one which, when facing a vulnerable server, would have lead to the creation of this /shell script server-side. These previous steps could have been really anything which would have coerced the server or the service it runs in somehow generating this /shell file or accepting to upload it.

In your comments, regarding the second option you seem to wonder why to act in two (or more) steps. When an attacker gets its first foot on a target, most often he has to face various limitations in terms of size and content of the payload he may execute (for instance he may be able to upload/create only ASCII files, or the content must be shorter than 100 characters, etc.).

Therefore, in order to fully-compromise a machine, he will first drop a first-stage payload which will be the bare minimum allowing him to download a full fledged binary payload as a second step. The classical way is to create server-side a script which will run any shell command passed as parameter (a classical web shell). Access to such web shell would produce exactly the same kind of log than quoted in your question.

And at last, as to why proceed with the following steps if the previous apparently did not work, again two possibilities:

Depending on the exploit details, it happens that the attacker may have no definitive feedback during the first steps allowing him to clearly define if the server is vulnerable or not. He will know it if the attack succeeded and contacting `/shell' URL does not throw a 404 error message but properly download and execute the second stage payload.
Some bots scanning the Internet are developed in a quick and dirty way and just blindly execute all steps of a given attack on all servers found in an IP range, ignoring the server response. Vulnerable machines, by executing the second stage payload, will call-back the attacker by themselves.


How to go about working with professionals online if you're developing a new encyrption algorithm?

I would suggest simple conversations with experts in the field to start with. Once you are more certain of the unknowns, prepare to file for a patent. In doing this, you'd research existing patents to make sure yours is unique. Once your patent is filed, post it on here or crypto or journals/etc to get feedback from the community of experts. You can skip the patent if you dont care about money or attribution.


How do you determine if an open source script contains malicious code?

Based on the rather generic requirements, I must say that there really are oh so very many ways to do malicious stuff, and even more ways to hide or obscure those activities.
For example, perhaps it only gets triggered after 3 months of use?

On the other hand - if this is open source, I would suggest auditing the code.
You can definitively verify anything and everything the code does, even under a very specific set of circumstances. Code coverage, and all that...
(Well, assuming there is not a rootkit in your compiler...)


DAST Output in Burp and Understanding It

I haven't used the new DAST scanner, but it seems like it injected (dkezib%2527%2522``'"/dkezib/>xrpjqc&) into the input field / variable, ran the javascript, and found that it reached the eval() without being escaped. Usually that's all the ingredients you need for javascript injection.

I would start playing with variations of alert(1) and see if you can get a popup. It probably won't work the first time and you'll have to take a closer look at the page source to figure out why. After an hour of this, I've usually either succeeded in getting a popup (confirmed vulnerable), or understand the code well enough to be 90% sure that it's not vulnerable.


Understanding how to prevent rapid-fire login attempts

The main idea here is to quickly slow down the window for brute-forcing an attack.
You normally implement this like:

Track on an account base. (so each account has its own wait time)
Increase the wait time exponentially.
Have an reset mechanism for the password and or wait time through some person (Admin / service desk / etc.)

The main difference between normal throttling and the login throttle is the wait time mechanism. the exponential factor means that you quickly have to wait for more than a day per password entry (effectively blocking that account), making detection of abuse much more likely, and normal throtteling you count connections / throughput per time, and have a stable amount of allowed actions in each slot. (so its a constant rate of attempts instead of a quickly diminishing amount).


Checksum Calculation for Source Code tar balls downloads

Checksums are there just to inform you that nothing has been damaged during download process. You must know that checksums have nothing to do with security features such as encryption. They are there just to be sure with a certain degree that what you got is what you expected. A more secure and better solution is to check the PGP signature as when you try to download a Kali Linux ISO image file.

As for HTTPS, there is the famous MITM attack performed practically for example using the notion of SSL striping developed by Moxie Marlinspike.

What I want to say is that when it comes to security you can never be safe 100%, but in your case it is better to download something from a website that combines reliability (checksums) and trust/security (HTTPS)


Security of php code on webserver - obfuscate?

By principle, PHP runs on the server side, only its HTML output is visible on the client side. This means NO need to obfuscate your PHP code as you do with JavaScript or other client-side scripting languages.

So the security of your PHP application code depends entirely on the security of your server itself.


Can a non-PCI Compliant Service Provider provide SAQ A-EP compliance?

Yes, SAQ A-EP requires your hosting provider be validated to all applicable PCI DSS requirements.

To quote the SAQ A-EP itself (emphasis mine):

  SAQ A-EP merchants confirm that, for this payment channel:

  ...

  If merchant website is hosted by a third-party provider, the provider is validated to all applicable PCI DSS requirements (e.g.,
  including PCI DSS Appendix A if the provider is a shared hosting
  provider);
  All elements of payment pages that are delivered to the consumer’s browser originate from either the merchant’s website or a PCI DSS
  compliant service provider(s);


Objectively, how effective are malware removal tools at detecting infections?

The best numbers I've found so far are in the Microsoft Security Essential Report 19 where they show at page 89 that with full real-time protection the infection rate is still at about 2..5%.

Then there are numbers from the Cicso Annual Security Report 2016 where they claim a time to detection at about 20 hours, but adware and browser injections are at about 200 hours.

  Is 'undetectable' (as in through traditional mediums) malware possible?

With APT (advanced persistent threats) the time to detection is weeks..years. Last average I've heard was about 200 days. So I would consider this as 'undetectable' at least for a long time. But even non-APT malware is designed to be as stealth as possible with a large amount of infections because the more persistent the infection is the better is the return of investment for the attack.

The big question is always what is really malicious. For example you could not simply declare software as malicious which reads data from the local disc and talks to the internet because this would not only include information stealing malware but also mail programs and browsers. And the less obvious the malignance is the harder it will be to detect the malware.


Try  nmap -Pn 192.168.0.171, also confirm try nc -z -v -w 1 192.168.0.171 80 if that does not work.


GnuPG asks for a key ID when sharing my public key, what is that?

OpenPGP User IDs

User IDs in OpenPGP are used to connect keys to entities like names and e-mail addresses. These are used to search for keys on key servers, and matching them to users/e-mail addresses.

Be aware user IDs are not checked by key servers, make sure to verify them on your own!

OpenPGP Key IDs

OpenPGP key IDs (and fingerprints) are used to reference keys when performing several actions like requesting and sending keys, or when verifying ownership. For example, you'd exchange the fingerprint with the key's owner on a separate, trusted channel to make sure the key really belongs to the person that claims to own the key.

The OpenPGP (v4) key ID is an identifier calculated from the public key and key creation timestamp. From those, a hashsum is calculated. The hex-encoded version is called the fingerprint  of the key. The last (lower order) 16 characters are called the long key ID, if you only take the last eight characters, it's the short key ID. An example for my own public key:

fingerprint: 0D69 E11F 12BD BA07 7B37  26AB 4E1F 799A A4FF 2279
long id:                                    4E1F 799A A4FF 2279
short id:                                             A4FF 2279

The primary public key's ID is referenced in the pub line after the key size, in your case the short key ID is CB3AF6E6:

pub   4096R/CB3AF6E6 2015-12-24 [expires: 2016-12-23]

Be aware the eight byte short key IDs do not provide a sufficiently large value space, and it is easily possible to generate duplicate keys through collision attacks. Instead of short key IDs, use at least long key IDs, and when software handles keys, always refer the whole fingerprint.

For more details on how the hash sums are derived, I refer to RFC 4880, OpenPGP, 12.2. Key IDs and Fingerprints which also explains the differences for deprecated OpenPGP v3 keys.

Sending and Receiving Keys From Key Servers

To send or receive keys from key servers, you must use the full key ID or fingerprint. GnuPG does not accept user IDs here. From man gpg:

--send-keys key IDs
    Similar to --export but sends the keys to a keyserver.  Fingerprints may be
    used instead of key IDs. [...]
 --recv-keys key IDs
    Import the keys with the given key IDs from a keyserver. [...]

If you want to search for a user ID (or parts of those) first, use gpg --search-keys. This will first query the key servers for the name, and provide some kind of assistant that asks you which keys to fetch afterwards (so, it will automatically run --recv-keys for the selected keys).

 --search-keys names
     Search the keyserver for the given names. Multiple names given here will be
     joined together to create the search string for the keyserver. [...]


How would one scan a large, untrusted file?

You may not be aware of this, but VirusTotal saves the files that you upload.  Businesses that have a subscription to VirusTotal can download those files you uploaded, it's part of the terms of service.  I wouldn't upload anything potentially sensitive that you don't want the entire world seeing.

While VirusTotal is indeed a useful service, I don't see it being beneficial to scan everything you encounter.  Assuming you're running Windows, any of the big players in the AntiVirus game such as Windows Defender, should be sufficient most of the time.

Is there a reason you're worried about this game installer?  Is it from a legitimate source, or is it something you grabbed off a P2P service?  Things such as games which unpack giant executables aren't as likely to be caught by AntiVirus.   There's a lot more space to hide something malicious that seems innocuous.

For something that size, I would recommend running in a sandbox.  Cuckoo will analyze files and executables dynamically.  Sandboxie doesn't analyze files, but rather provides isolation, so if a program is malicious they won't be able to touch the rest of the computer.


Why doesn't the CPU verify/enforce matching call/ret addresses?

Your idea sounds like ROP Defender although that is a software implementation.

This would make buffer overruns harder, but while I can't think of a way round it just now, I expect some smart exploits could get round it. So what you propose is effectively another kind of anti-exploitation technique - it would be a sister to Stack guard, DEP, ASLR, etc.

When considering anti-exploitation techniques there are two main considerations: compatibility and performance. These techniques are only used when there is a very good pay-off. My gut feel is that this won't cut it - too much performance pain for too little benefit. But who knows, maybe it will get implemented.


Mapping the public key to an IP address is easy (just hash it and keep the first 80 bits) and you have listed the ways to make this somehow robust (i.e. make the transform slow). It has the drawback that it does not solve the problem at all: it just moves it around.

The problem is about binding the cryptographically protected access (namely, the server public key) to the notion of identity that the human user understands. Human users grasp domain names. You will not make them validate hash-generated IPv6 addresses...

Of course there is a deployed system which maps names to technical data such as IP addresses; this is the DNS. You could extend it to map domain names to public key verification tokens (i.e. put the hash of the public key somewhere in the DNS), or even public key themselves. If you use the DNS to transfer security-sensitive name-key bindings, then the DNS becomes a valuable target, so you would have to add security to the DNS itself. At that point, you have DNSSEC, which is a current proposal for a replacement of the X.509 PKI for HTTPS Web site. Whether DNSSEC would fare better than existing CA is unclear; that's switching actors, but the conceptual certification business would still lurk here.

Humans want human-readable names, and public keys are unreadable. All the certificate-based solutions (be they X.509 or DNSSEC or whatever) try to bind a public key to an arbitrarily chosen name. Another distinct method would be to make the public key readable. Strangely enough, there are cryptographic protocols for that: ID-based cryptography. They use some rather tortuous mathematical tools (pairings on elliptic curves). They do not change the core concept (really, at some point, someone must make the link between a societal identity, like "Google", and the world of computers) but they change the dynamics. In an ID-based system for SSL, each server would have very short-lived private keys, and a central authority would issue to each server a new private key every day, matching its name. The net effect would be like an X.509 PKI where revocation inherently works well, so damage containment would be effective.

Yet another twist would be to replace the notion of identity. Since humans cannot read public keys, then, accept it: they will not read them. Instead, track down active attacks with specialized entities, who do know how to read keys. That's the whole point of the "notaries" in Convergence. The notaries keep track of what public key is used by which site, and they scream and kick whenever they see something fishy.

Anyway, the current system is not broken -- not in an economically relevant way. The breach you are linking to will join the Comodo and DigiNotar mishaps; that's a short list. Such problems occur way to rarely to even show up on the financial radar: if you add up the cost of all frauds which used a fake server certificate obtained from a "trusted CA", you will get an amount which is ludicrously small with regards to the billions of dollars from more mundane credit card frauds. From the point of view of banks and merchants and people who do commerce on the Internet, the X.509 PKI works. There is no incentive for them to promote a replacement. If there was a fake Google certificate every day, used to actually steal money from people, then the situation would be different. Right now, we are around one event per year.


How to exploit via Metasploit vulnerabilities found with Nessus?

CVE is only the vulnerability report, it doesn't necessarily mean that it is exploitable. Also, we are very fortunate that even if exploitable, not all vulnerabilities have publicly available exploits, and especially ones that are available within the Metasploit framework. Otherwise we would have lots of script-kiddies running around armed and dangerous!

On the question of CVE-2014-3515 - this is something that is listed as "exploitable using common tools" - meaning that you can create a PHP script that exploits the vulnerability, e.g. you don't need specially crafted shellcode or a compiled binary. Looking at the original detailed report of the vulnerability on php.net, it is relatively easy to create an exploit, given that one has a solid understanding of the PHP programming language, which most scripties don't have. \o/


Securing shared key in TOTP Implementations

Because it's necessary for the algorithm to work, valid codes can't just be generated out of thin air. Users should be told not to share the QR code. The fact that it's being used for 2FA should hopefully be enough for most people to understand that it shouldn't be shared, but some implementations could certainly be improved here.
The key must be per user. If it were the same key for all users, all users would be generating the same codes.
Tell the user not to share it, and follow good security practices to make sure your app isn't vulnerable to things like SQL injection that an attacker could use to get all the secrets.


Protecting data on server from illegal physical access

I need to create a shell script and put in /etc/init.d/my_script to remove my data if unauthorized physical access is detected.

In general, "Having a VM self-destruct if unauthorized physical access is detected on the host system" is almost impossible. Are there other details about your situation, beyond what's already in the question, that would make this problem easier (ie remotely possible)?

In fact, there is a set of industry standards that specifically address the problem of wiping data if physical access is detected. This is the FIPS 140-2 standards which apply to Hardware Security Modules (HSM). In particular, FIPS 140-2 Level 3 and Level 4 deal with detecting intrusion. Devices that meet this spec are purpose-built with specialized hardware to detect intrusion, you will not be able to do this on an arbitrary ESX VM.

Your best bet is A) to buy an HSM (they start at $500 and go up to tens of thousands of dollars) then B) use keys stored on the HSM to encrypt the sensitive data on the VM so that even if someone clones the VM they will not be able to access the data without the HSM being plugged in. As pointed out by @Neil Smithline, even this is defeated by cloning a running VM since the decryption keys and/or the decrypted data will be in memory.

If you really want a simple script-based solution there are some things you can do which will deter casual attackers. But I will not recommend any because they are basically pure security theater and will not stop anybody with even a little bit of hacking training.


Best practice for password-protecting a secret key

PBKDF2 is designed exactly for the purpose you're thinking of: to make the time tradeoff for attacking a low entropy source comparable to that of attacking the resulting output as if it were a purely high entropy source.

In a contrived example, I might make my password using one of four numbers. The resulting key could be one of 32 numbers. To make them equally secure against brute forcing, it need to take as long to test one of the four keys as it would to test seven of the 32 keys (32 / 4 - 1 because the resulting 1/32 must also be tested). To protect against rainbow tables, adding a salt would also be helpful.

PBKDF2 accomplishes those above tasks of slowing the process and uses a salt. Unless you're running your output from it through something that has a comparatively slow operation process, then taking the output from PBKDF2 would be appropriate.

Other key strengthening designs such as bcrypt can also be an option. In any method you use, make sure that your output is at least as many bits as your key needs to be. You can hash to a smaller size, but never use hashing to get a longer key.


Properly configured, a server should always return the correct content for any URI.  That's the definition of a URI.

As for your second question, it depends on configuration.  If multiple IPs are being routed through the same NIC, the MAC address will still be the same and would identify them as going to the same interface.  If multiple physical interfaces are used, it would become much more difficult unless the server is leaking other identifying information though.


How much risk by sending id and card via email?

Two things I can think of:

I think you can run TLS check against the receiving email domain to verify whether TLS is set up properly on their end. And if you use large mail provider like Gmail you know your side is good. (But I could be wrong in understanding how email TLS works..)

Second thing is you can potentially encrypt the attachment separately, send over email, and somehow communicate with the support the decryption key.


JPEG artifacts leaking information about redacted contents

JPEG compression is a form of transform compression using DCT. A quick Google gives this overview of the algorithm:

http://www.dspguide.com/ch27/6.htm

Now the important bits here are:

8x8 (or whatever size you set during compression) fragments are independent of each other
Most of the compression happens in the high frequency components

The #1 point is the most practically useful one. If your redaction allows you to add ample border space, extending it by the fragment size ensures that all the related information is likewise lost.

The #2 point is something that someone else can potentially elaborate on. Essentially, to be recovered by forensics, the correlation between the pixels to be reconstructed would have to impact the final encoding in a statistically significant way. That does not seem to me to be a trivial task. However, as JPEG is deterministic, educated guesses can be verified, or even brute-forced.


What does that sensor actually do, and how does it prevent someone from pushing a small thing in the crack and changing it to (try to) trick the sensor?

This sensor is called a REX or Request to Exit. The sensor is meant to allow people to leave an area without having to badge or authenticate leaving the area. Your question is good because the idea of pushing something through and attempting to trigger the REX is something that has been accounted for. The devices can be configured to only test a certain range, such as 4 feet from the top of the door.

The best practice is to have the REX aimed at the door handle so that it triggers when someone is actually trying to leave the area, but having the range configured so it should not trigger if someone is trying to stuff something under the door. Newer sensors often utilize IR to ensure that it is not an inanimate object, but a person trying to leave the area.

The combination of having a properly configured REX as well as IR sensors in the REX reduces the likelihood of a vulnerability and increases the odds that the door can only be opened when someone is on the inside attempting to leave.


How can I get notified about the publishing of ransomware decryption keys

Several security companies and also Europol and other policy agencies maintain together the site nomoreransom.org. This site tries to offer a single place for information about current ransomware and also for the current tools which are available to decrypt the data.


Does HTTPS protect against DNS rebinding?

TL;TR: HTTPS will help against DNS rebinding.

Each new TLS session established by the browser validates the subject of the certificate against the domain of the URL. With DNS rebinding the victim initially visits a attacker controlled domain and after an attacker controlled DNS change the IP address for this domain changes to point to same (maybe internal) host.

After this DNS change the domain in the URL is still the attackers domain which means that the browser expects the certificate for the new TLS connection to match this domain. But, the new target host has only a certificate for its own domain and not for the attackers domain. This means that the TLS handshake will fail, either because the server refuses the handshake since the SNI name in the ClientHello does not match the servers configuration or because the browser will reject the certificate from the server since it does not match the name in the URL.


Firefox: What would be more secure/private: storing session cookies or saving password in the browser?

I would argue that storing passwords in the browser is more secure than using cookies and staying logged in. But the best option over here would be to have your cookies deleted after every session and using a 3rd party password manager extension like lastpass with a strong master password for managing your login credentials.


If a smart card has multiple certificates on it how do go about choosing the appropriate one?

As I understand it, the server can influence the selection of client certificate in 2 ways:

It can specify the acceptable CA's that signed the client certificate
It can specify the acceptable types of certificate ciphers

If the client has multiple suitable certificates, they will be presented with the selection dialogue.

This should be true no matter where the certificates are stored, not just on a smart card. Of course, with a card, it is possible that you might be using a client app rather than just a web browser and in that case, it would be up to the app to help clarify the purpose of each certificate and can call on data in the available certificates to assist.

With the UK's NHS smart card for example, several certificates may be present. Each one represents a clinicians role in a specific organisation and the "Identity Agent" client software presents the list in a human readable way.

This is not possible in a browser situation.