How hard would it be to crack bcrypt hashes if the salt is unknown?

I think you've misunderstood the purpose of a salt, because if you understood what it is designed to achieve you perhaps wouldn't be asking this question. The only purpose is to provide a level of uniqueness to each password in order to prevent precomputed tables ("rainbow tables") being an effective form of attack.

As a result, it's not designed to be "secret" or add entropy to the password in any way, and that is why it is stored alongside the hash of the password. In fact in most cases it cannot be secret because the application itself will need access to the salt in order to calculate the correct hash of the password. It's very difficult to allow access to the application, but prevent an attacker who has breached the application from obtaining the same privilege.

Anyway to answer your actual question - in a theoretical world where you had to "crack" the salt because it was unknown, and could not be retrieved for some reason, it would be exactly the same level of complexity as passwords. Basically (character space)^(length).

In your example you give a hash of "H0mRpD2XJZDguAzxTehwzu". Assuming upper / lower case alphanumeric that's a character space of 62 characters, and it has a length of 22 characters. Hence 62^22 = 3.397504e+23   years of guessing assuming 1 billion guesses per second. In other words, uncrackable (this is even assuming the password is known and you're trying to simply guess a system wide salt).


My friend was fired from her job. Overnight, on her personal phone all her work contacts mysteriously disappeared

Well then, to try and fully answer your questions:

  Is it possible someone hacked to her phone and delete all her work contacts?

I will say this with a resounding no. It's theoretically possible for them to hack into the device, but while not only highly unlikely it is also impractical for anybody to remove just her work contacts.

The company has no reason: These are just names and numbers and do not violate any non-disclosure agreement I've ever heard of. They would have no reason to hack into a device just to remove contacts. See my explanation below for this.
No other person has any reason: What would any other person outside of the company gain from deleting those specific contacts? Nothing I can think of.

The most likely scenarios are:

These contacts were revoked because her phone (personal or work) were synced to Exchange/ActiveSync, or some other method that the company had control over that would allow them to revoke this information. It was mentioned that she used Wi-Fi to connect the devices

PEAP and RADIUS are a common authentication/authorization protocols used on WPA2 Enterprise networks that can install profile information on certain types of devices, by signing in you agree to certain terms and conditions that may involve the ability to remove information from your device. This they are legally allowed to do because it allows them the ability to control whether or not an employee steals/leaks information.

As mentioned by user Jeff Medden, it is possible contact information was synced across an iCloud account (if it was an iOS device), whether your friend knew it or not. People often run into this without understanding the boundaries of what iCloud can control (which is a LOT).
Negligence. This could mean she entered them in and thought she saved them, but didn't. It could also mean she intended to have them sync to iCloud, Google, etc. and it didn't (I've personally done that one).

There's not much else to throw at that one. I'll just tell you that people make mistakes and your friend may have made one without realizing it. Jumping to the conclusion that a company hacked her is a little farfetched.

  What can she do to find out if her employer have breached her phone?

Let's say the company really did breach her phone then yes, there are ways to find out.

However, they're probably beyond your means or ability to do so. Even having a specialist look at the device will probably yield no results.

  How should she go about this situation?

She doesn't, and really, she can't.

If they hacked you (which I laughably doubt), you have to be able to prove it and prove that it was not legally within their means to do so.

I would just tell you that if you want these contacts to try and reach out to these people via LinkedIn or whatever means you have and leave your paranoid ideas at the door.


Advanced techniques for detecting a proxy/getting original IP

the site literally was able to print my originating IP address (from the US) and deny me access. Shouldn't this be impossible?

It sounds like you're expecting anonymity.

Proxies can be elective about whether or not they send the X-Forwarded-For header (which contains the originating IP).

A proxy that doesn't send this header, or record the originating IP in logs, is said to be an "anonymizing" proxy. In the case you mention, the proxy you were using likely forwarded this header to the endpoint you were accessing, so your connection was not anonymized.

There are multiple ways to detect whether or not your traffic is of proxy origin. Two easy ones are:

Presence of the X-Forwarded-For header (or custom data in forwarded headers)
Cross-checking known IPs of proxies or exit relays (TOR)

databases maintained by third parties (e.g. Quova)

There are other ways, possibly requiring additional intelligence on the server, perhaps to correlate requests across connections from different IPs, i.e. looking at user-agent criteria and timing of requests, cookies, LSOs in flash,  (one of the reasons you'd want cookies and Flash player disabled to really anonymize yourself).

In short, just "using a proxy" alone does not make you anonymous or untraceable.


Is it OK to store encryption key on Windows fileserver?

This totally depends on whether it meets your risk assessment for the task in which you are using it. It maybe totally fine or it maybe a very bad idea.

You need to know. What are the results of your risk assessment and what are your security policies?

No one on here can answer this without a more detailed question relating to the what you are are wanting to secure.

Just make sure if you do this that it meets all of your policy and legislation/compliance requirements you maybe following.


Can a website detect malware or virus present on device / PC?

It is unlikely, but that also depends on what they might classify as a virus/malware. To answer this, one needs to consider what types of access a website has to a client that is visiting it.
JavaScript can be used to probe a bit about the system:

Your coarse location
Installed extensions
Device info
Information about services on your local machine or network (port scanning)

Most of these aren't very likely to provide indication of any malicious software being present. It is more likely that they detected a suspicious login attempt from a device (maybe the device appeared to be in a different location) and somehow assumed one of yours was compromised. Seems a bit overkill.


Are HTTP brute-force password-guessing attacks common nowadays?

I prefer to call them "online password guessing attacks" since "brute force" has a specific meaning that may not always apply to these attacks.  But yes, they do still happen and here are a few example stats for you:

Microsoft: “we detect more than 10 million credential attacks every day across our identity systems.”

Akamai: They observed “999,980 IPs were involved in the attacks against [a financial institution] customer's login page.” 427 million accounts were checked in a one week period.  Also saw 817,390 IPs making 388 million login attempts using 65 million email addresses against an entertainment industry customer.  Comparing source IPs of both attacks, they found 70% match, implying the same org was responsible for both attacks, or that they used the same botnet.

Google: “We’ve seen a single attacker using stolen passwords to attempt to break into a million different Google accounts every single day, for weeks at a time. A different gang attempted sign-ins at a rate of more than 100 accounts per second.”  This was reported in 2013, but I'm sure they still face similar attacks.

Taobao: Taobao was attacked via an online guessing attack over a few days in Oct 2015.  The attackers used 99M credentials collected from other sites. 20.5 million credentials matched Taobao accounts, which was about 1 in 20 of their total annual active buyers.  Wasn’t detected until November, however Alibaba says at the time their security systems discovered and blocked the vast majority of log-in attempts. Still resulted in around $1 million of fraud transactions on their site.

In these cases these sites may have rate limiting or other adaptive authentication controls in place, but they aren't 100% effective in preventing all account takeover attempts.


While importing certificates in keystore, do we treat these like CA root certificates?

I think you are slightly confused. Self-signed cert CAN be a root cert. When you are calling your internal domain via HTTPS, in order for TLS handshake to succeed (and, consequently, for communication to proceed over HTTPS) your local service needs to trust the server's CA. For that reason you import that CA into your trust store, thereby trusting the ID certs that the CA will sign. The ID cert is a certificate that the server will present during the TLS handshake.
Let me know if I need to clarify further. Getting confused by X509 is the easiest thing to do:)


Accept a https connection with invalid certificate and validate the certificate before. Is it possible?

What your partner said is somewhat legit and ok from security perspective.

TLS is established between client HTTPS library and TLS server, not server app! Server app delegates TLS stuff to TLS server (Apache, IIS, dozens of them). Partner is planning to ignore certificate errors at TLS level (between client and web server). Instead, they apply certificate validation logic in web application. They simply check certificate details for every connection and if certificate fails, they will respond to client with error using client-server data protocol (SOAP, Web API Result, HTTP code, etc.).

In other words, there are two levels where certificate validation occurs: on TLS server and inside web application. They bypass all errors on first level and will handle them on app level.


How To Protect My Personal University Account from an SSID spoofed AP?

With Captive Portal connections, about the only thing you can do is to ensure that the captive portal site is accessed only via HTTPS and make sure that the certificate is correct. If you get any kind of a certificate warning, don't connect.

You also need to take some care not to have non-secured network connections running at any time. Make sure any email clients are connecting securely and remember anything that connects without encryption, even once connected to Wi-Fi is potentially vulnerable.

You can also assume that something is always monitoring your traffic even with a valid connection. Stay clean. Don't connect to anything daft.

If you need extra protection for some reason, consider connecting via a mobile phone if you have sufficient data.


How can we prevent and detect any unauthorized screen capture and recording applications?

Short answer: this is a classic form of spyware/malware.

It is not so common anymore because the data it collects (images) has to be interpreted by a human, so it's not efficient.

Lots of technical controls are in place to prevent this. For instance, the login screens for an operating system are run outside of the user's operating space, so this type of malware cannot typically record you logging in (there are variants that can actually do this, but I have not heard of them in a long while).

Anti-malware software is designed to look for this type of behavior and will alert you about it. I'm not sure how complete the coverage is on this by the vendors.

Looking for unknown processes in the background and inspecting traffic going to unknown or unexpected locations helps to detect this sort of infection.

But as I said, it's just not efficient to carry out this type of attack, not when you can make billions with dodgy emails that have an infected PDF that installs ransomware.


Does having 2-factor authentication help with HeartBleed?

I disagree with Mark. A main goal of SSL/TLS is the protection of the long term key (i.e. the private certificate). If an attacker can obtain the key, the implementation must be considered broken.

It does not matter if you use two-factor authentication or not. If I know the server's secret key, I can decrypt your traffic either directly (without PFS) or via MITM (with PFS). I can steal your session cookies or whatever and do everything without your token. I can even steal your TCP sessions.


Let me address your root question (pun intended):

  Question: what is difference between bought CA and self-signed CA? Because as I understand in both cases I need to install CA on server to validate client certificates.

Background

To answer this, let's make sure we understand what a certificate is. When you have a public key / private key pair you can give the public key to whom ever you want, it's public, but how will people know that it's actually your public key? Imagine this scenario: Alice sends her public key to Bob, but Charlie intercepts the message and replaces Alice's public key with his own. Bob has no way of knowing that the public keys were switched because all he sees is a public key. Now Bob thinks he has a secure connection with Alice, when in fact he has a secure connection with Charlie who's pretending to be Alice.

Certificates solve this problem of knowing whose public key you have. The process is that I will contact a Certificate Authority company and prove to them that I am who I say I am (exactly how they want you to prove this is answered in this question). Then I can submit my public key to them and they will bundle it into a certificate, which contains the public key itself and a bunch of information about who I am. The CA will sign the certificate to say "We certify that this public key belongs to this person", and so that the data in the cert can not be modified. Now I have an "official" document proving that this public key belongs to me. Now there's no way for Charlie to pretend to be Alice.

In most cases, you will not be requesting a certificate for yourself as a person, but for a specific server within your company, or in your case clients, but the idea is the same.

Answer

You have 2 ways of getting your public key made into a certificate:

You can submit it to one of the publicly trusted root CAs of the internet (Digicert, Verisign, godaddy, letsencrypt, etc) who will issue you a certificate (for a cost),
Or you can make your own self-signed CA and issue yourself a certificate.

The only real difference between the two comes down to public trust; if you pay one of the public roots to certify your public key then every computer on the internet will automatically trust your certificate to be genuine and authentic because they trust the CA's reputation. Zero extra work for you.

If you make your own self-signed CA then every computer will say "what is this, and why should I trust it??" (remember that Charlie can easily make his own CA and create a certificate with Alice's name attached to Charlie's public key). So you will have to manually go onto every computer that needs to validate one of these certs and tell it to trust your self-signed CA by adding the self-signed root certificate to that computer's "Trusted Root Certification Authorities Store".

Advice

Making your own self-signed root CA is not necessarily bad, it depends on what you're trying to do. In a lot of cases, having your certificates be publicly trusted on the whole internet does not add anything. For example, in a corporate ID badge system to get into the building; who cares whether those ID badges are publicly trusted or not - you only care about whether the door scanner recognizes them. Or client certs on embedded devices; the devices will need to authenticate to a server to receive firmware updates - only that server will ever need to validate the certs.

If your use-case is one of these "closed system" use-cases, then by all means, use your own self-signed CA.


Enterprise HTTPS redirection without certificate error

A captive portal is essentially doing a man in the middle attack. HTTPS and other protocols using SSL/TLS are explicitly to detect and prevent such man in the middle attacks. This leaves you with two choices: don't do a man in the middle attack or make the client trust the man in the middle. All fully transparent solutions require that you have some control of the client.

Trusting the man in the middle is in many cases possible if you can add the man in the middle CA of the captive portal as trusted to the client. In some systems like windows this can be done in an automated way (group policy). If browsers will see that the certificate is signed by this explicitly added CA they will also disable checking of public key pinning (explicit and builtin HPKP). But note that it will not work in all cases, i.e. there are non-browser applicatons like Dropbox which continue to do certificate pinning and thus will not work any longer.

Non doing a man in the middle attacks works if you configure the captive portal as an explicit proxy in the client. If proxy autoconfiguration is enabled in the client this can be done with a WPAD server, it can be configured with group policy or it have to be manually configured. With a proxy you could request authentication. But you are limited to either basic authentication (username and password) or to transparent authentication using NTLM. There is no way you could first present some information to the client which he has to accept. Proxy authentication also only works if the client knows that it is talking to a proxy. Simply intercepting normal HTTP/HTTPS traffic and sending back a proxy authentication request will not work. This also means that applications which are not aware of the proxy (i.e. don't use system settings) will not work.

And finally you could abandon any attempts to redirect the user and simply post information which describes that the clients should first authorize themselves using some internal URL. Until this is done any access simply fails and once the client has authorized himself the MAC of the specific client is allowed for a while.


Import the existing password hashes along with the rest of the data, add a 'dirty bit' flag to the new database and set it to true for these imported users.

When the user goes to login have it validate using the hash mechanism that was used in the legacy app/code, then force the user to update their password using whatever the current method is, store the new hash, and turn off the flag.

Bit more work on the back-end but if you take the time to set it up right it makes any future switches easier and makes it much smoother for the end user to transition.

Edit: Plus, you avoid the potential (read as surefire) mess that is setting a user's password to NULL or blank. How is anyone supposed to verify that the end user is the 'actual' user?


Bypass PHP strtoupper() to perform SQL-injection on MySQL database?

Use the sql CHAR() fonction for every character that needs to be lower case, put the whole request in a string using concat.

SET @T = CONCAT(CHAR(109),  CHAR(121),  [...]);
PREPARE A FROM @T;
EXECUTE A;
DEALLOCATE PREPARE A;

I tested it and it works well.

edit: showed the wrapping in proc


There is nothing wrong with "wildcard certificates". A wildcard certificate is equivalent to a certificate containing a lot of possible server names. If this maps well to your problem (e.g. you have a server with a lot of frontends who advertise distinct names, but all these names are in the same domain and you control that domain), then wildcard certificates are certainly a possibility. The main issues with wildcard certificates are:

A wildcard certificate is usable with several server names, and you usually need to use several names because you have several machines. Since the wildcard certificate corresponds to one private key, that private key will have to be installed on all these machines. Private keys which are duplicated and which travel around are somewhat less private, because they are more exposed.
Commercial CA use a business model that relies on selling many certificates. A wildcard certificate allows a customer to buy one certificate instead of many. Thus, commercial CA tend to make wildcard certificates much more expensive, to compensate for the corresponding loss of business.

In your situation, as I understand it, you have a hosting server, who runs a SSL server for several sites; the sites have names which follow the pattern name.example.com where name is a customer-specific name, and example.com is a domain under your control. Since, in HTTPS, the SSL dialogue occurs first (before any HTTP occurs), the server does not (usually) know the intended server name (the name from the URL which the client uses), the server must somehow send a certificate which "works well" with all possible names from the client. This leads to three possible solutions:

Use a wildcard certificate with *.example.com. This will work well.
Use a certificate with many names in the Subject Alt Name extension. You can put hundreds of names in there. This also works, but you have to obtain a new certificate every time you want to add a new name (a certificate is signed by the CA, you cannot change anything in it without invalidating the signature).
Make the server "guess" the intended server name, so that it may send the "right" certificate (the server would then have many certificates, one for each site name). This uses the Server Name Indication extension: a slot in the early SSL handshake messages so that the client may tell to the server, before the server actually sends its certificate, which site name the client is expecting. SNI works well except that some old browsers or OS do not send it, so using this extension means that you will not support such clients. The main unsupported client is Internet Explorer on Windows XP (IE on newer Windows systems is fine). If you think you can afford to reject clients who still use Windows XP and IE, then SNI is a workable solution for you.

The wildcard certificate still seems the simplest and most robust method.


Is it possible to get data out of running application from non-rooted phone

Your assumptions about rooting a phone are not necessarily correct.  The most typical way is to unlock the bootloader, since it allows root to be granted at boot time, however a flaw in the OS could result in it being possible to root the phone without unlocking the bootloader. While I am not aware of any current ways to do this against Android 4, it was very possible in versions prior to 2.2 and there was even a virus that rooted on a running phone that made it in to the wild.  This is likely why that particular flaw (which had been used to root phones for some time) was finally patched.

Rooting only requires some exploit that will allow for permissions to be elevated to the superuser context.  There are many ways this could be done, just most people don't bother to try and find them since they just want to unlock their devices and the bootloader is the path of least resistance.


How to protect/mitigate IntelME (CSME) JTAG attack over USB?

The attack works by exploiting the USG JTAG debug feature found in some PCs.

Years ago, if a computer manufacturer was debugging their motherboard design, there would be a special port on the motherboard called a JTAG port to poke around registers in the processor/chipset. https://en.wikipedia.org/wiki/JTAG

To use this port, you would need a JTAG debugger device.
https://www.sparkfun.com/products/12942?gclid=Cj0KCQiA_5_QBRC9ARIsADVww16L8y1WKfZ9aiJQttvILJoygVQd1LTmss5_MiPobTO2I9NbCziFwfQaAo0cEALw_wcB

On modern motherboards, there is often no room for a JTAG port. And in the case of something like a laptop, it may not be feasible to get to the JTAG port. So, Intel developed a way to access JTAG via one of the USB ports.

One of the USB ports on the chipset (typically port 0) is a “special” USB port that allows JTAG debugging with a special USB device.
http://www2.lauterbach.com/pdf/dci_intel_user.pdf

In the BIOS settings for a PC, there would typically be an option to enable USB debugging, and this option should be disabled by default in any production systems shipped to customers. However, there are some computer manufacturers that have not followed best practices:

They turned debug on by default during HW/BIOS development and forgot to turn it off.
They hard-coded the state of USB debug in the BIOS to enabled, and did not provide and option to disable it.

If you have access to the USB debug/JTAG function, you have “better than root” access to the system. It is intended for the hardware and firmware designer to troubleshoot low-level system issues. The exploit is really about JTAG, not Management Engine. If an attacker can get to the JTAG port, they own your computer, period. Intel Management Engine is just something they can exploit while they have control.

I will also point out that USB JTAG as an attack vector isn’t exactly brand new: https://www.digitaltrends.com/computing/intel-kaby-lake-skylake-pcs-hackable-usb-jtag/

One of the fundamental laws of computer security is that if a bad guy has unrestricted physical access to your computer, it isn’t your computer anymore.  JTAG is an example of that rule.
https://msdn.microsoft.com/en-us/hh278941.aspx

So what do you do to stop this?

Don’t let a bad guy have physical access to your computer. If you suspect this has happened, stop using your computer immediately and get a new one.
Check with your manufacturer for a BIOS update.
Disable USB debug in the BIOS if you can.
If you do not have an option to disable it, contact the manufacturer of the computer/motherboard to see if they have it enabled. If they do, you have to wait for them to provide and update, or replace the computer.


A more secure way? Use https along with this. There are two vulnerabilities here:

When the user logs in, the password that is sent over can be easily read by anyone snooping on your connection. This can't happen on an https connection.
If a user is already logged in, someone snooping on your connection can just copy over the session cookies. In HTTPS, cookies are transmitted securely, so there isn't much of an issue.

You may also want to log the user IP address and not let them switch, though this may get annoying (for a user like me who is behind a university proxy with rotating external IPs, I'll never be able to log in).

A final observation: Don't use GET for the log out bit.. Try not to use GET for anything which triggers a change -- it's fine for navigation, but not for anything which will lead to something changing on the server (a logout, or anything that writes to a database). See the prescribed usage of GET and POST for more details.

If you implement the above, then also make sure that the referrer of a POST request is your site and not some other site. (This, along with the above, will help prevent CSRF attacks).

To prevent clickjacking, disable framing via javascript and the X-Frame-Options: deny header.


How many known time/result combinations does it take to guess a HOTP/TOTP secret?

Have a look how the HOTP (TOTP is just a special case based on a time for now) is calculated. It is using HMAC based on hash function either SHA1, SHA2 (or MD5 in worst security case) of secret seed and some counter. It is returning some part of the result as a PIN.

As an attacked intercepting the PINs, you are trying to find out a secret seed of unknown length.

Based on the definition of hash function, it not reversible (unless it is broken). You can not simply reverse the operation even if you would have the whole hash. But you have 6 to 8 decimal numbers. You also do not know where they fit into longer decimal string -- this is also changing based on last byte).

So what are the options you have? The easiest way would probably be to brute-force all the possible values for seed (for example 32 B hexadecimal string) and compare them with the intercepted data. This could work with the TOTP since you can know also the time when it was generated (30s time frames). But in the HOTP, you have no idea what the counter is (unless you would manage to intercept all the PINs.

I would say, the strength of the OTP is its complexity of the algorithm and simplicity of use. I am not giving a proof why it is hard, but I hope the answer summed your question and answers why you can not simply do that.


Used laptop with potential BIOS/SSD firmware malware

Hypothetical questions like this are difficult to answer and are thus discouraged. In order to be able to receive specific answers, you would first actually need to have been infected by the malware. Second, you would need to be capable of discovering, extracting, and analyzing said malware before anybody would be able to tell you what you should be worried about. So, I will hypothesize about the worst case scenario.

  1) If I assume that the BIOS, SSD, or NIC firmware is indeed compromised from the previous owner, what are some of security features that something like Qubes OS will provide me despite this?

Without knowing the exact capabilities of the malware, the worst case is that Qubes will not offer any protection. Since those components are at such a low level, compromised firmware could allow unobstructed access to all hardware and software on the computer. Virtual machines are no more secure than the hypervisor they are running on.

  2) I have read that installing AIDE/Tripwire on dom0 at the beginning of a fresh Qubes OS install can be a powerful tool to see whether the BIOS malware infection is going to damage the dom0 and other downstream VMs in any way going forward. Do you think this is useful?

It would be interesting to see the source of this claim. If the BIOS is truly compromised, capable malware could likely hide itself from any sort of userspace detection, so this wouldn't do you any good. AIDE/Tripwire keep track of file integrity, and I believe they encourage use of an external database so that it is less likely to be tampered with. Even if the malware needed to modify your userspace files, it could also probably replace or interfere with the functionality of these tools to evade detection.

  3) The manufacturer website has downloads for BIOS firmware, SSD firmware, wireless LAN/WAN, etc. My BIOS and other firmwares are 1 year out of date. If I update these firmware over windows, and then wipe windows from SSD and start a fresh Qubes OS install, will the firmware stay updated? And will it also remove potential malware that was previously infected?

Again, this depends on the capabilities of the malware and the method in which firmware is updated. Maybe the malware doesn't allow its firmware to be overwritten through the normal vectors. The only way to override anything like this would be to flash the chip directly with SPI or JTAG.

  4) What are some good practices for preventing these types of firmware attacks? My system uses TPM 2.0. Is there a guide to get TPM2.0 working with dom0 to check and analyze logs? Is it a good practice to turn off/not update intel ME, disable intel TXT, AMT, and secureboot? Because that is what I did.

The only way to prevent it in this case would be to buy a computer that isn't already compromised. I do not know what TPM has to do with logs. Without looking each one up, those Intel components may add some unnecessary attack surface and should probably be disabled. I also don't know of a security-based reason for why you'd turn off secure boot, since it can prevent some attacks (but won't likely provide protection against this type of malware).

TL;DR: maybe don't worry so much about something like this, since it's theoretically very hard for anybody to defend against it, even a security expert. If you really have to worry, buy a computer from a trusted source and don't ever let it out of your sight.


How to catch a SMS spammer who is using google voice to spam me

Don't play cops and robbers,  just report the issue to Google and they will take care of it.  Google and the authorities have better tools and people who are paid to deal with these criminals.

That being said,  one way to identify someone online via chat or sms is to get them to visit a URL.  This could load a page that logs the IP address, and then you can perform a whois or geoip lookup on this address.  More advanced/blackhat/illegal method would have that URL return a page that exploits a vulnerability in the browser and then you can collect personal information from the spammer's machine.


Unsure of what you're asking so I will answer based on what I do understand:

  if theres a port scan on the same segment and it does not reach the
  firewall at all, it is not detectable by anything.

This makes little sense. If there is a port scan on the same NETWORK and it does not reach the firewall, it is not detectable by anything? Consider the following internal network:

Network     10.10.10.0
Subnet      255.255.255.0
Router      10.10.10.1
Firewall    10.10.10.2

If I am on 10.10.10.3 and scan 10.10.10.4 my port scan may or may not be detected on the firewall depending on your configuration. Once upon a time, there was "PortMagic" port scan detector for Windows, but I would not install that on ANYTHING but a home PC. It is not a commercial tool, and even if it was, you would likely confuse your users or make them paranoid.

Secondly, attackers can mangle portscanning by using decoys, and unless you configure these automated tools properly, you're doing more harm than good. For example, if you configured an automatic block, consider I scan your machine with the IP of 10.10.10.10 with the following syntax:

nmap -sS -vvv -D 10.10.10.2,10.10.10.1 10.10.10.10

-D 10.10.10.2,10.10.10.1 these decoys that I am using will be blocked by 10.10.10.10 which means that machine will be offline. Just because a machine is being portscanned, doesn't mean someone WILL hack that machine. It all boils down to whether or not the machine is vulnerable, and whether or not that vulnerability is EXPLOITABLE.

Think of a house. Every house has windows. Every house is vulnerable. Your house has a security guard on duty, with Rottweilers inside a fence around the perimeter. I can assure you that your house is not exploitable. At least not as easy as the house without any protections. However, even this analogy is not that great because some houses have more windows than others. What is behind those windows? (e.g. what services are you running that someone can exploit.)


Use a logging server.
Have all your servers immediately send all events to a common logging server.  Then the hacker can delete all your files, but its to late the logged events are already out the hackers immediate reach.

Then, your next concern is making sure the logging server doesn't get compromised.  The logging server should ONLY be a logging server with all other services turned off.  All other ports beside the incoming log traffic should be dropped.  Ideally, another network interface on a private lan would be the only way to talk to this server.


Ubuntu/Debian Is it okay to use a sudouser account as my primary on a workstation?

In fact it does not matter much.

The admin / normal user separation comes from the world of mainframes, back in the previous century; it was expected that a given computer was used by several (many) users, often at the same time, and these users do not trust each other. The OS enforced separation, and becoming "administrator" allowed for bypassing that separation, and thus was the ultimate goal of any attacker. In that models, attackers are the users themselves.

In modern computer usage, especially for "workstations", there is only a single user on a given machine. Your computer is yours; thus, you are not an attacker. It is expected that you can become an administrator whenever you wish it so, and, in practice, since you have physical access to the machine, it would be hard to prevent you from doing so. Attackers, in that model, are external people who want to access your data (not root's data, but yours). The attacker wins if he gets to run his code with your privileges, because then he can plunder all your data, and/or use the machine as a relay host to attack other machines. In modern workstation usage, there is no strong security need for user/admin separation. You still want to log in as a non-root account (but still sudoer) to protect you against accidental mishaps: as a non-root, if you want to make your machine unbootable, you have to do it on purpose. Anyway, due to the longstanding firmly entrenched Tradition of mainframes, modern Linux distributions frown upon opening sessions as "root", in the same way that playing satanic hard rock might offend the Pope (although that's not guaranteed with the current incumbent).

What you do with your machine will fall somewhere between these two models, but probably closer to "modern workstation" than "mainframe". As a rule of thumb: if your machine does not run a SSH daemon (sshd), then you are in the "modern workstation" model and user/admin separations are irrelevant; you can be a sudoer as much as you want.


Wondering what "v" is, in SJCL Library encryption output

Judging by the source code, it's a version number of the ciphertext, but the value v is never set or used. Also, it is not documented, so this is pure speculation.

Normally, a version number is not required, because checking which fields are set should be enough to determine the format of the ciphertext. Since the ciphertext format of SJCL is stable, the version number was never changed and it doesn't lead to any special code depending on the version number.


It is still mostly the case that liability for computer breaches (not including disclosure of private information) is legally blameless. There are plenty of laws cropping up all over about data privacy, but as far as protection of computing resources themselves there isn't really a standard. "Gross negligence" on the Internet is still a basically non-existent standard. Thus, for ultimate liability you're probably in a very safe spot.

That said, nothing prevents a case from being brought and incurring court-related fees including legal representation. Investigations of misuse of your server may not result in any charges, but you could lose your servers for a long time while they're impounded as evidence. Law enforcement in the US at least is not known for very fast turnarounds.

Applying patches is usually much less expensive than either of those outcomes.


TLS provides various ciphers, some are more optimized for hardware (like AES based ciphers) and some for software (like ChaCha20-Poly1305). Thus proper choice of the cipher can reduce the overhead needed for encryption. And use of these ciphers only marginally increases the size of the transferred data.

The other part of performance problem is the initial TLS handshake. But since your API is already TLS anyway you could just reuse the TLS session and thus save both time (less handshakes) and power (less heavy computations).

Another way would be to shift the performance problem by transferring pre-encrypted files. In this case you don't need to securely transmit the full data but only the small encryption key. The bulk of the data could then be transferred using an insecure transport protocol, like pigeons. If this is a better idea in your case highly depends on the unknown details of your actual use case.


The servlet engine you are using securely handles session cookies when you call request.getSession(), and is not vulnerable to fixation.

(as discussed in the comments) This behavior is both intentional and correct. Whether getSession(), getSession(true) or getSession(false) is called, the server relies on its own memory to determine if there is a valid session matching the value received from the client. If there is no such session in server memory, then the servlet engine ignores the session id from the client. This prevents session fixation, since the server never allows the client to define the sessionid of a new session (new from the perspective of the server that doesn't have that sessionid in memory.)

You either need to find an older, broken servlet engine that is vulnerable to session fixation or you need to replace the session management code. If you go with the latter, you will need to determine if you can replace the session generation in place or if you will write your own session management code.

The approach you take should mirror what you are trying to teach. If you want people to teach...

keep your stuff patched, then go with the broken old engine
not to write your own session management mechanism, the write your own
not to modify an existing session management mechanism, then modify the existing one


Signing and encrypting with pairs of keys based on discrete algorithms

In general, the answer is no, not necessarily: even if a signature scheme is secure in isolation, and an encryption scheme is secure in isolation, the combination of the two with the same keys may completely wreck security.
For some particular discrete log groups, some particular encryption schemes, and some particular signature schemes, the answer is yes.

Degabriele, Lehmann, Paterson, Smart, and Strefler studied the security of combining ECIES with EC-Schnorr (related to the popular EdDSA scheme with the popular Ed25519 instantiation), and of combining ECIES with ECDSA[1].
The security of EC-Schnorr is reasonably well-understood, while the security of ECDSA is rather complicated and not as well-understood[2] (paywall-free).*  The conclusion of Degabriele et al. was that those two combinations provide essentially the same security as their components—i.e., high confidence in ECIES/EC-Schnorr, and not-very-well-understood confidence in ECIES/ECDSA.

Signal uses a combination of X25519 and Ed25519 called XEd25519[3].  I'm not aware of a formal security analysis of it, but I expect that the security are quite close to the Degabriele et al. results on ECIES/EC-Schnorr.

However, there is no limit to what can go wrong if you stray outside the bounds of combinations that have been studied.  When GnuPG played with the fire of keys reused for Elgamal signature and encryption twenty years ago, they got burned so badly that a single signature leaked the private key[4].†
So make sure to ask your cryptographer for advice about the particular encryption scheme and the particular signature scheme want to reuse keys for before you try this at home.
And this is all aside from the qualitatively different security requirements of signing keys and decryption keys in practical terms: if you can revoke a signing key then it doesn't matter if it is later compromised, but a decryption key can never be revoked to prevent retroactive decryption of past messages except by comprehensively erasing it from the universe.

* To be clear, I am not talking about the catastrophic failure of pre-RFC 6979 ECDSA or DSA in the face of a broken random number generator at signing time—a failure mode which Debian and Sony learned about the hard way, and objections to which fell on deaf ears at NIST when the DSA was first proposed in the early '90s[5].  Rather, I am talking about the security of ECDSA even when used exactly as directed.
† In fairness, this wasn't exactly because the private key was reused between signing and decryption—rather because the security criteria for private keys in Elgamal encryption and Elgamal signature are different, and optimizing the performance for encryption ruined the security for signature.


What is the name of the crypto system used by ICANN's DNS recovery system?

IANA operation details on the root key ceremonies and procedures are at https://www.iana.org/dnssec
You may be interested by section §4.2.2 of https://www.iana.org/dnssec/dps/ksk-operator/ksk-dps.txt
   Access to and management of cryptographic hardware is based on the
   principle of successive barriers in three tiers, requiring at least
   seven trusted persons from four different roles.  These barriers are
   as follows:

   Tier 5:
         Physical access to safe room requires one person from the Key
         Ceremony Administrator role in combination with one person from
         the Internal Witness roles.

   Tier 6:
         Physical access to cryptographic hardware (HSM) and activation
         material requires one out of two of the Safe Security
         Controller #1s, and one out of the two Safe Security Controller
         #2s in addition to the Trusted Persons required at Tier 5 and
         7.

   Tier 7:
         Activation of a HSM requires three out of seven Crypto Officers
         to extract activation material from above safe deposit boxes
         using their physical key.  Safe deposit box operation that
         involves opening of any one of the deposit box requires three
         out of seven Crypto Officers to be present.

   Restoration of the contents of a HSM requires at least six trusted
   persons from two different roles, as follows:

   Secret share:
         Reconstruction of the secret key used for encryption of the
         application keys requires five out of seven Recovery Key Share
         Holders.

   Encrypted application keys:
         Physical access to the encrypted application keys requires one
         person from the Ceremony Administrators role, one person from

And section §5.2.2:
5.2.2.  Private key (m-of-n) multi-person control

   The RZ KSK Operator has implemented technical and procedural
   mechanisms that require the participation of multiple trusted
   individuals to perform sensitive cryptographic operations.  The RZ
   KSK Operator splits activation data needed to make use of the RZ KSK
   private key onto separate smartcards controlled by trusted
   individuals (Crypto Officers) selected from members of the Internet
   community not already part of root zone management operations.
   Specifically, organizationally separate parties, not affiliated with
   PTI, ICANN or Verisign.

   A threshold number of smartcards (m) out of the total number of
   smartcards created and distributed for a particular hardware security
   module (n) is required to activate a RZ KSK private key stored on the
   module.  The threshold number of cards needed to sign using the RZ
   KSK is three out of seven.  The smartcards are protected in
   accordance with Section 5.4.2.

Typically, when you create a key on an HSM, you can generate various Officers access to it, and decide how many of them will be required to unlock the private key. You can find example at Standards for secure key backup of master keys with secret sharing
Note that is it not about "for recovering the DNS registry  in the event of some catastrophic failure. "
DNSSEC adds cryptography in the DNS in the sense that each zones signs its records with some key and some (other) key are stored in the parent and so on until the root. IANA (ICANN) handles the root procedure-wise and for the ceremonies and such, while Verisign manages the day to day operations of it (technically of the A root nameserver, which is the one from which all other ones derive their configuration).
So the question is more around how the root key is protected, and what happens when it is lost. But even outside of those edge cases, the root key ceremonies also need multiple crypto officers to unlock the key when it is needed (twice per year). You will see in mainstream media sensationalist articles about the 7 people to have the keys to the Internet (example of such bad writing: https://www.theguardian.com/technology/2014/feb/28/seven-people-keys-worldwide-internet-security-web), while https://www.cloudflare.com/dns/dnssec/root-signing-ceremony/ will give you both a more accurate description with more real technical details.
You can see at https://www.iana.org/dnssec/tcrs the current list of crypto officers (needed for bi annual key rotation ceremonies) and the "recovery key share holders".
The first one are needed to just unlock the private key, the second ones to reconstruct it if it gets lost/damaged/unrecoverable/etc., per §5.2.4:
5.2.4.  Private key backup

   Encrypted copies of the RZ KSK private key(s) are backed up onto
   portable media held by the RZ KSK Operator and sent by courier to the
   other facilities.  The key used to encrypt the private key(s) is
   backed up using a five out of seven threshold scheme with smartcards
   distributed to trusted individuals (Recovery Key Share Holders)
   selected from members of the Internet community not already part of
   root zone management operations (specifically, organizationally
   separate parties, not affiliated with PTI, ICANN or Verisign).  The
   Recovery Key Share Holders keep the cards in tamper-evident bags,
   stored in geographically dispersed locations under their control.


Which IPTables chains should I log from a security perspective

FORWARD:

It can be beneficial to log the FORWARD chain to doublecheck that routing decisions act as intended or to check that logic holes in the rules that you know to exist are covered. Often, logging the FORWARD chain is very targeted.

PREROUTING:

There is not a lot of value here to log because you will get flooded with noise. Unless you have processes in place to sort out the signal-to-noise ratio, there is little benefit.

POSTROUTING:

Because this happens after all the rules have fired, you should already know what is going to be in this log. If you want to know what bad things might have passed through, you would be better off running IDS systems after the firewall to give you this intelligence. The signal-to-noise ratio is also "off" at this point, but in the opposite direction: if you know how to properly identify the noise in the signal, then you would also be able to craft the rules properly. So, not a lot of actual benefit.

There may be other benefits to logging at these points, but from a "firewall security perspective" I'd stick to the higher value chains.


Per-host authentication and configuration of ssh files

It sounds like you want to use Host Based Authentication, and there is a good source of information at the OpenSSH wikibook site. Link here

Please keep in mind that any host based authentication has inherent security issues, and you should be diligent with configurations to ensure only the approved accounts and processes are allowed to utilize this feature.


Browsers and export regs. Is SGC still valid?

US export laws still apply, but they have been relaxed.
Excerpt from the Wikipedia page on Export of Crypto in the US:

Current status
As of 2009... Some restrictions still exist, even for mass market products, particularly with regard to export to "rogue states" and terrorist organizations. Militarized encryption equipment, TEMPEST-approved electronics, custom cryptographic software, and even cryptographic consulting services still require an export license. Furthermore, encryption registration with the BIS is required for the export of "mass market encryption commodities, software and components with encryption exceeding 64 bits". In addition, other items require a one-time review by or notification to BIS prior to export to most countries. For instance, the BIS must be notified before open-source cryptographic software is made publicly available on the Internet, though no review is required.

So while registration with BIS is still necessary for the vendors of encryption products, they can then export software which uses stronger ciphers.
You, as an end user, or server admin, do not need to worry about this!


Pattern to allow multiple persons to decrypt a document, without sharing the encryption key?

You need a per-document key, not a per-user key. Well, you also need per-user keys, but that is another matter.

Namely, each document D is encrypted with a key KD. That key is generated randomly the first time the document is imported in the system. Each document has its own key. The key for a document cannot be inferred from the key on any other document.

Each user U also has a key KU. Therefore, if you need document D to be accessible to users U, V and W, then you store EKD(D) (encryption of D with the document key), along with EKU(KD), EKV(KD) and EKW(KD) (encryption of key KD with the keys of user U, V and W). These "encrypted keys" have a small size (a few dozen bytes, regardless of the document size) so this scales up.

To make things more practical, you may need to use asymmetric encryption for user keys: encryption of D uses a convenient symmetric system (say, AES), but the "user keys" will be of type RSA (or another similar algorithm like ElGamal). That way, if user U wants to share the document D with user V, then he:

retrieves EKU(KD) from the server;
uses his own private key to decrypt that and recover KD;
encrypts KD with V's public key, yielding EKV(KD).

The beauty of this scheme is that V needs not be present for this procedure, since only V's public key is used.

At that point, what you really have is OpenPGP, a format meant primarily for secure emails. Emails have this "sharing property" (an email may be sent to several recipient) and are asynchronous (when you send the email, the recipient is not necessarily available right away). You would be well advised to reuse OpenPGP, a format that has been reviewed by many cryptographers, and for which implementations already exist.

When you have a sharing mechanism, you can simply put yourself as implicit recipient for every document, and you can read everything. Regardless of law requirements, be sure to notify users through the "usage conditions" that you can technically read everything; otherwise they may sue you for lack of warning.


How do sites detect credential sniffing, and what is the purpose of this attack?

We can't know how Unsplash detected it unless they tell us.  However, many large websites have some sort of abuse tooling to automatically detect patterns.  For example, Unsplash may import compromised credentials from public databases and match logins on those accounts from certain shared IP addresses.  Clearly they've seen this pattern before since they have a pre-canned email about it.
In general, any site of reasonable size that has a social aspect where there can be likes or ranking of items is subject to abuse from bots who sell paid likes.  As for who would want this, consider being able to put on your resume that you're one of the top ten most popular photographers on Unsplash.  That would be very appealing indeed.  It may also cause search engine rankings for your user ID or name to be better, especially if they show up on a favorites or top photos page.
As for why the attackers uploaded images, because it's very easy to find empty accounts that only give out likes.  If a user engages in a variety of types of activity, it makes it seem less suspicious, so the site is less likely to catch on to the pattern.  They also may like unrelated accounts to make it less obvious who's paying them if they do get detected.  Most sites don't permit gaming the system in this way (or using automated systems to do this) and the attackers' service wouldn't be very popular if many of their customers' accounts got cancelled.


Getting a DEP exception when trying to call SetProcessDEPException(false)

Finding functions come in two flavors:

Exported - Super easy.

In Windows use

HANDLE kernel32 = GetModuleHandle(L"kernel32");
FARPROC funcAddr = (FARPROC *) GetProcAddress(kernel32, "SetProcessDEPPolicy");

This will return the address of the function if it's exported by the module, in this case the module is kernel32.

Non-exported - Annoying

The first step is to manually find it first through some sort of reverse engineering.  This can be rough.  If you know of certain constant error types it might return you can narrow down the search to a handful of procedures.  Windows loves using constants, and they document their use in the MSDN.  Sometimes unexported functions are documented by other researchers, or if you're lucky enough to be doing this on an open source project you can look for the constants there.  But really you have to find the function through good old fashion RE.

You can take it a step further to make this easier on yourself in the future.  Find a unique byte stream to the function.  Then write your own function that can search a given image for that unique sequence, and calculate the offset to the beginning of the function.  Boom you have an address.

Of course using this dynamic searching is not guaranteed from version to version.  Maybe the compiler took a different optimization on SP1 than SP2?  The unique stream then becomes invalid.  But that's really the best option you have for unexported functions.


Securing an API with Django Rest Framework

Can I do this via the Django Rest Framework, and if not is there a package for Django that does this? (If this isn't possible, is there a reason it's not implemented?)

This cannot be done via the Django Rest Framework, and the djangohmac package suffers from the timing attack vulnerability identified by @Dogeatcatworld.

  Is this a safe authentication scheme given my goals (only the person in possession of the token can generate valid requests, no replays, etc.)?

No, not completely. In order to be safe, the timing attack vulnerability needs to be removed. I.e. rather than checking signature == expected_sig which will terminate at different times due to where in the string a discrepancy is found, an algorithm that checks the whole string regardless needs to be used.

def is_equal(str_a, str_b):
    equal = True
    for i in range(min(len(str_a), len(str_b))):
        if str_a[i] != str_b[i]:
            equal = False
    return len(str_a) == len(str_b) and equal

Note that this still leaks the expected signature length, potentially.

  Is there a better, more idiomatic approach?

That looks like it.

  Is it even necessary to seek a third-party library, or are the edge cases limited enough that a home brewed solution--accompanied by unit tests--is sufficient?

Use the python libraries for all of the cryptography and do the length check yourself--that's fine.


If you're asking whether a generic email provider such as gmail has PCI compliance issues because of what it's users may do, then no.  Consider the DSSv3 definition:

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

While the situation you're talking about involves a case where the service provider is used to "transmit cardholder data", a generic email provider is not an "entit(y) involved in payment card processing" (at least not insofar as it's customers use it to send email; it may be insofar as it might charge those customers, but that's a separate issue).

The individual sending the mail has PCI obligations because it's their data, the carrier does not because it isn't.


Why can't we use POST method for all requests?

HTTP has different verbs, which have different semantics:

GET : does not change anything server side, multiple GET with same parameters should get same response - typically get an account value
POST : can make changes server side, multiple POST with same parameters can lead to different results and responses - typically add an amount to an account
PUT : can make changes server side, multiple PUT with same parameters should lead to same result and response - typically set an account value

DELETE and HEAD also exists but I do not think that you want use them here.

As POST is not idempotent, major browser will warn you if you send twice the same POST request which is not desirable in GET use cases.

Anyway, headers in the HTTP request control where the response should be cached or not, so it is possible to ask caches to not keep responses to GET requests.

Finally, caching (in the sense of caching proxies) is not security related. If you do not want someone to eavesdrop your requests and reponses, you should not worry about caching but use HTTPS which ensures that everything is correctly encrypted.

Browser caching is a different question, because then can store the last URLs in their history cache. So sensitive information should not be send in the URL, unless you consistently clean the history when you close you browser, and close your browser when you have finished browsing a site. But sent in URL and sent in a GET request are different questions. HTTP basic authentication allow to pass the credentials in the HTTP headers of a GET request, which is safe. And login form authentication is an non idempotent request (the state after and before authentication is not the same) so it shall be a POST request per HTTP semantics.

TL/DR: The problem is not in GET vs POST request. The rules for confidentiality are:

always use HTTPS
never pass sensitive data in URL.


Your proposed mechanism is not secure.

Anything available to JavaScript is available to the person running the client browser.  Base64 encoding only mildly obscures the answers.  Even encrypting them using strong crypto like AES will not work because the JavaScript must have the key.

Would someone go the trouble of figuring out the Base64, or encryption?  It depends on how cool those prizes are and is anyway security by obscurity.

You can deal with this in one of two ways.  The simplest way is to send all the answers to the server at the end of the quiz and check them on the server with PHP.  If you want to provide feedback for each question, you should make an Ajax call after each question is answered.

I can't really tell about your second question because there isn't enough detail.  However, everything related to security must be done on the server.  You can pass an opaque session ID back and forth between server and client, but you can't do anything on the client that forms a basis for the security of the system.

Finally, I worry about "some salt values."  Rolling your own crypto is not safe unless you have a Ph.D. in mathematics and ten or more years' experience with cryptography.


I would use an open source implementation of OAuth.  Even better,  you could use a 3rd party OAuth provider so that you don't have to worry about leaking your customer's credentials in the event of a compromise.


Logging is based on the threats you perceive and also what you might find valuable during an actual security incident.

Another slightly different alternative would be to log any attempts to access a session that expired. Thus you're not logging when a session actually expired. Instead you're logging the moment a user or attacker makes a request against a session that already expired. This should be low resource for coding since you already have the session Id and you're already checking if the session is valid or not so just log in your code the moment you determine Its and invalid session.


How to describe RC4 'bias' to non-tech people

I think explaining the weakness in RC4 to a non-technical audience would be very similar to explaining the role of randomness in crypto to a similar audience.

Let's say I want my army to attack at dawn, so I encrypt the message "attack at dawn," generate a ciphertext c_0, and send it to my army, who then attacks my enemy at dawn. Great.

Next week, I want to attack at dawn again. So I use a different key and encrypt my message "attack at dawn" again, to generate a ciphertext c_1, which I then said to my army. Imagine I do this n times to produce n ciphertexts.

If my enemy can read the messages I send, he will look for patterns (biases) in the messages I send right before my army attacks at dawn. If there is something similar with all these messages (e.g. they all start with a "?" character), my enemy might be able to guess that any message beginning with "?" corresponds to "attack at dawn." However, if you can't find any pattern in the ciphertexts, the enemy learns nothing about your communication.

The weakness in RC4 lies in the fact that the same message encrypted with different keys produces ciphertexts that have common patterns (statistical biases). These are usually much more subtle than beginning with the same character, but the point is the same.


How bad it is to install another company's root certificate to your server?

So we had to install their root certificate "PrivateCompany Root CA" to our web server.

Why? Globally trusted CAs are useful in general purpose clients like browsers.

But if you consume specific web services from a custom client you can add that CA locally. Every decent SSL client allows you to influence certificate validation. For example by specifying a custom list of CAs.

If you you do it this way, that CA can only be used to intercept those requests. Since the CA and the target domain are owned by the same entity, this doesn't pose a big risk. It's safer than using the standard CAs.

  Just how bad is this exactly?

If they (or somebody who managed to steal their CA cert) are in a MitM position relative to your server they can intercept any SSL traffic where your client uses the global CA storage. It's not limited to their domain.


What's a term to describe multiple shoulder surfing attacks to uncover different parts of the password?

I don't believe there is an official term. I might coin the phrase: "Constructive Shoulder Surfing" or "Iterative Shoulder Surfing"


Is there a guide of general/common IT vulnerabilities?

It's not exactly a guide, but I believe CWE - Common Weakness Enumeration is excellent source of common software vulnerabilities (not just web) and it is up to date. And of course for web application, the OWASP site contains a lot of useful information about web application vulnerabilities.


Is accessing /proc/ inside docker container a security breach?

What you're able to see from the process running in the Docker container is a filtered view of the hosts /proc filesystem.  It's somewhat less than what any process running on the host could see.

on Q1 Whether this is a security breach depends very much on the environment you're operating in.  For most environments, this isn't likely to be an issue, you might want to ask your colleague what exactly he thinks the problem is (i.e. what information is being disclosed from those locations that compromises the security of the environment)

On Q2 bind mounting /proc is a somewhat different story as that will expose a lot of information into the container which may be sensitive.  Again it may or may not be a problem depending on your environment, but it's a more risky prospect.


Transmit over CAN-FD a RSA-ecrypted and signed message, how to deal with message length?

Finally found it, don't why it took so long: 2048 bit after encryption, because doesn't depend on the length of the message to encrypt, and 256 bytes of signature. So 512 total bytes to transmit in 8 different 64-bytes CAN-FD frames.


What are the pros and cons of outsourcing an organization's PKI?

One of the key risks I have come up against when working with banks outsourcing their PKI is the protection of the root certificate. If you are relying on your PKI to protect something which is business critical you really want your PKI provider to assure you of the security around the root certificate.

There are a few providers who really work hard at this, using many mechanisms to help persuade clients to use them. From experience, I include in this pressure plates, retina scanners, dual synchronised keys, man traps, video coverage of root access, partial access granted to the provider, and part to you - pretty much everything you'd expect from an evil genius in a James Bond film.

Another issue is around connectivity - if you use the PKI for real time services, loss of connectivity to the provider will cause a Denial of Service. Make sure they have resilient links to you, and to your customers or other users.


Can MiTM and similar attacks be performed on separate networks

It depends on what type of MitM attack you want to do.

arp spoofing or any type of attack which relies upon Layer 2 will not work across routing domains.

However, you can perform other attacks such as modifying a host file, DNS spoofing, or other attacks at the network level. You could attack the router itself so all traffic is directed to you, etc. You could trick the victim into installing malware which will redirect all requests to your server first.

If your specific host is being blocked at any point, you can use another machine or compromise another machine to try to find a valid path to your victim.


I think Trey Blalocks answer is great, but I would like to complement it with some math.

If your password is randomly picked from the 171,476 words in the Oxford English Dictionary you get log2(171476) or about 17.4 bits of entropy.

Lets assume there is about 4 natural leet substitution in the average word. Randomly either doing or not doing each substitution adds one bit, so adding the leet would increase the entropy by 4 bits, meaning it takes 16 times as long to crack. (If you just use leet for all available substitution you just add one bit - the password is either leet or not leet.)

On the other hand, a completely random 8 character alphanumeric (upper and lower case) password has log2(62^8) or about 47.6 bits of entropy. That means it takes a bit more than a billion times as long to crack!

So adding leetspeak is slightly better than just taking an english word, but it is not nearly as good as randomizing.


How should I escalate a vulnerability that is dismissed by the vendor?

You could:

try to persuade why this vulnerability is so severe and what consequences customers may have;
try to sell to companies like ZDI;
go full disclosure - provide detailed description and solution, e.g. patch;

I suppose there are no other ways how you could put your vulnerability fixed. Also, in your recent topic Was the ASP.NET Padding Oracle exploit exposed in an ethical manner?  What could have been done differently? you were already pointed to How to disclose a security vulnerability in an ethical fashion?.


Are there any reasons to be concerned about the security of "Coin"?

You're confusing the key size of symmetric algorithms such as 128 bit AES and the key size of an asymmetric algorithms like RSA, which would need an estimated 3072 bit key to achieve a similar level of security.

The problems I see are not so much with security. It seems like that would be a slight overall improvement over a regular printed mag stripe card. My concerns are with missing functionality. It won't do EMV. It won't do NFC. It doesn't protect against skimming attacks. And it will be obsolete in 2015.


RFC 5246 TLS 1.2: padding example mistake?

The document is correct, xx is the last octet of the MAC, followed by six times the 06 octet as padding, followed by the length octet (06). The last length octet is not part of the padding.

See the definition of GenericBlockCipher in section 6.2.3.2 of RFC 5246:

struct {
    opaque IV[SecurityParameters.record_iv_length];
    block-ciphered struct {
        opaque content[TLSCompressed.length];
        opaque MAC[SecurityParameters.mac_length];
        uint8 padding[GenericBlockCipher.padding_length];
        uint8 padding_length;
    };
} GenericBlockCipher;


Technically, yes.

The answer, in simple terms, is "yes" to all of your questions.

The firmware (BIOS or UEFI) loads before the operating system. Typically, it looks for a boot sector on your storage devices (internal HD, CD/DVD, USB drives, etc). Then it loads the bootloader specified in the boot sector into memory and passes control to that boot loader, which will get the rest of the operating system up and running.

If the firmware is infected with malicious code, it can read/write anywhere. File permissions are implemented by the OS kernel or the file system driver, so they aren't a concern at all in this situation. This means that you are free to tamper with the OS files as well.

But also, no.

In modern systems, this is very difficult to accomplish, however.

The firmware controls access to the EEPROM, which is where its code is stored. Modern motherboards will usually only accept firmware updates which have been digitally signed by the manufacturer. You would have to defeat this mechanism first if you wanted to tamper with the BIOS/UEFI.

Newer operating systems can validate digital signatures on their files.  If you tamper with their files, the digital signature will no longer be valid. E.g., if you enable SecureBoot on Windows 10 and change something it will refuse to boot.

Obviously, you could edit the OS to strip out the digital signature checks if you control the firmware, but it is very difficult to infect firmware for several reasons.

In addition to the built-in protections, the firmware on most motherboards is customized for that individual model or, at most, that particular product line. Writing a firmware hack that applies to a wide range of motherboards is extremely difficult---and may be practically impossible.

All things considered...

It is theoretically possible to tamper with a system in this fashion. The potential for abuse is well understood, however, so the danger is addressed with reasonable technical measures.

People with physical access to your machines could flash the EEPROM chips containing the BIOS code with custom-programmed malware. It takes a lot of resources to orchestrate this, so the average computer user is not at risk.

This type of attack is easily within reach of governments and large criminal organizations. Governments and large firms are at risk, and they generally buy from trusted vendors or certified resellers to reduce the risk of acquiring compromised equipment.


What is the difference between full end-to-end encryption and end-to-end encryption?

There is no difference. End-to-end encryption simply means that both endpoints share a secret key which is used to encrypt all traffic between them. There is no difference between "full" end-to-end encryption and end-to-end encryption. It's like the (lack of) difference between forward secrecy and perfect forward secrecy. They're just different terms to explain the exact same concept.


The sending of SPAM is not necessarily related to whitelisting of domains and IP addresses.

You can get spam from whitelisted domains if users accounts are compromised or if the whitelisted domain is a generic one for many users/organisations.

The use of SPF, DKIM and DMARC (as mentioned by schroeder) enables you to check that email that appears to come from a specific domain actually comes from the servers advertised for that domain. Even that doesn't stop spam as bulk mailers and spammers often use legitimate host domains which will pass those controls.

Email security best practice is to ensure that any point-to-point mail server links you have (lets say with partner organisations) enforce mutual TLS and that you define your own SPF/DKIM/DMARC correctly in your DNS. Reject anything inbound that fails those tests and run good anti-spam software.


SSL Wildcard certificate to issue anther certificates

Unfortunately the PKI model as implemented in the browsers does not enforce a restriction of the domains you can sign with a CA, thus any sub-CA can sign any domain it wants. That's why no CA trusted in the browsers will issue such a sub-CA anymore (at least officially, they still might issue them to allow some agencies to mount man-in-the-middle attacks).
So you will not be able to buy a sub-CA which is only able to sign domains below example.com.

Even if you would be able to buy such a certificate the subject does not matter, e.g. it can be *.example.com or whatever. The subject is only used to find the issuing CA by matching the issuer name in the leaf certificate with the subject name of the known CAs when validating the trust chain.

Apart from that, a certificate is not signed with the certificate of the CA, but with its private key. So if the certificate of the CA expires you can just issue a new certificate with the same public/private key pair and subject and you don't need to re-issue all the certificates signed by your CA. But usually the validity of a CA is much longer than the one of the certificates issued by the CA. So you usually don't re-issue a new CA certificate because its not valid any more, but because the private key got compromised or it got too weak (e.g. replace 1024 bit keys with 2048 bit). In this case the public key changes so you need to re-sign the certificates issued by the CA.


Why would taking my laptop home be encouraged for security reasons?

So here's the TL;DR:

It's easier for you to maintain a watchful eye on the laptop than it is an empty desk other people can access in a large area to either infect it, or walk away with it

It's basically the same reason you don't leave your laptop in a public place:

  You don't know who has access to your laptop.

By bringing it home you've guaranteed you know who had access to the laptop. That's a big improvement when it gets compromised. Think of the conversation that would be had:

  "What happened during the time your laptop was compromised?"
  'I left it unattended on my desk overnight and possible thousand of people could have touched it.'

Or

  "What happened during the time your laptop was compromised?"
  'I watched a video on Youtube with it and it started acting funny'

The top situation is a 'I left it unattended' and the bottom is a 'We have a direct vector to investigate first as it was being used at the time of infection'. I know I'd always would rather deal with the second situation than the first if I were your IT department. Especially for the following reasons:

It was monitored
Anyone who could have had access to it must have had personal access to you and where you were
Your group of friends who would have access to it would be much smaller than a company(basically anyone who asked, and you'd remember them)

Those three reasons alone are a huge consideration besides the theft deterrent of an unattended laptop and why many companies decide to adopt similar practices.


Is the following code seeding OpenSSL's PRNG necessary, superfluous, or harmful?

With current and not-so-current versions of OpenSSL, this code is useless (but harmless), because OpenSSL will automatically seed itself on /dev/urandom on machines where /dev/urandom is available. This is documented:

  On systems that provide /dev/urandom, the randomness device is used to seed the PRNG transparently. However, on all other systems, the application is responsible for seeding the PRNG by calling RAND_add(), RAND_egd() or RAND_load_file().

Actually, the documentation is slightly wrong because on Windows, where there is no /dev/urandom, OpenSSL uses CryptGenRandom(), so the automatic strong seeding still occurs.

On machines where there is no system-provided strong PRNG, the caller must provide entropy "manually", but these systems are, by definition, machines where there is no /dev/urandom.

The contents of an uninitialized stack variable are hardly a good source of entropy, because such contents are usually very deterministic. Reasonable sources of randomness in a machine come from the "physical world", typically precise timings of hardware events.


How to replace certain backup files on a website every 30 minutes?

Reverting the changes every 30 minutes is not a solution. You absolutely need to find out the root cause and stop this from happening by removing the vulnerability or the persistence. This may include monitoring the logs and other forensics, but also a fresh installation of WordPress (or in worst case the entire server) might be required.


Does a hash of a 32-bit integer make a better hash salt than the integer itself?

Actually most implementations of algorithms like BCrypt will generate a salt on their own, from the random source of the operating system. This is the best one can do and there is no need to derrive a salt from other parameters.

A salt should be globally unique for each password, so an attacker cannot find any precalculated rainbow-tables, and would have to build a separate rainbow-table for each password.

Locally unique: If every password of your database gets a different salt, the attacker cannot reuse the rainbow-tables. Hashing the integer (user id) will not make any difference in this case.
Globally unique: If you use worldwide unique salts, an attacker cannot find already precalculated rainbow-tables. Finding precalculated tables for user ids is slightly easier than finding them for the integers hashes, so hashing would indeed improve security a little bit.

Once again, you can get a salt without derriving it from other parameters, and you shold do it. Let the hash function do it, or get it from the random source of the operating system.


How to store IV and key temporarily but securely

At least one thing you can improve rather easily: You can simply store the IV in the database next to the encrypted data. The IV itself is not supposed to be secret. It usually acts as a salt, to avoid a situation where two identical plaintext records get encrypted into identical ciphertext. Storing the IV in the database for each row will eliminate the concern over losing this data. Ideally, each row IV would be unique and random but not secret.

That leaves your problem to storing a relatively small piece of information: the key. There should be no issue using the same key for all records in terms of security. As long as the key itself is strong, using a different key does not give you any advantage (in fact, it will be a real headache to manage), so one key should usually be good enough.

There are probably many solutions to storing keys securely, but those depend on the level of security you really need. For .NET / Microsoft environment I am guessing you should be looking at DPAPI, although there may be better options out there. In one extreme, you'd need a HSM or a smartcard, but in less-stringent environments storing the key on the filesystem with the right permissions might be sufficient. It all depends on your risk profile and threats.


Is it possible? Of course, see the examples above and probably below.

Is it likely? Depends where you buy them.

If you buy random, too cheap to be true, refurbished smart phones from a nonreputable chinese vendor on ebay your chances of running into a smart phone with malware increase exponentially.

Unlike some stories about hacked devices and such, this is something that could be worth the hackers while though as today a lot of people will have banking, facebook, authenticator, etc apps on their phone so the attack vector is very real I would say.

On the other hand, to add some realism, buying a refurbished phone from a reputable source like a big brand, well known web shop or similar (you know the brands for your own country / area best) I'd imagine the risk isn't that high.


How should I react to finding GMail outbox e-mails that I didn't send?

Yes, it is extremely likely that your gmail password has been stolen. Those emails wouldn't be in your outbox if they hadn't been sent through google's smtp servers or mail API, and Google requires your credentials to send emails servers, so unless there's an unreported bug that allowed it your account has been compromised. You need to change your password, and any other accounts that use the same or a similar password.

You should also put some thought into how your account details have been compromised, and take steps to prevent it from happening again. It could be:

bad habits: you could have shared your password, written it down where it could be seen, typed it in where it could be seen, transmitted it unencrypted, chosen an easy to crack/guess password or used the same password on another site. You should do none of those things
Your computer was compromised: if someone's cracked your computer you will need to rebuild the OS from scratch, the "nuke it from orbit" solution as favored by @Polynomial
Google account information was compromised: this is the least likely, but still possible cause. If this is the case I'd expect it to come to light.


What are you doing if you notice a MITM attack against a Linux server?

If you notice that someone is actively man-in-the-middling a server the first thing you should do is inform your incident response/security team.

They should decide on mitigating controls, that's their task. It's highly dependable on what technology is being MiTM and in  what way. It also depends largely on where the MiTM is occuring. Aside from re-adjusting routes to go across another network, there's not much you can do.


Should user's password strength be assessed at client or at server side?

Password strength, in this context, is a meaningless concept. The strength of the password, in most cases, isn't an intrinsic property of the password itself. That input validation logic in registration forms merely checks the password against a certain criteria: Does it have a number? Does it have a special character? Is it longer than 8 characters? etc.

Such checks can be done in the client's browser or on the server. Enforcing those conditions, however, can only be done on the server as the user can simply bypass those client-side restrictions. Those checks are done in the user's browser because it's much faster to do them there; they're just indicators for the user. Once the password is submitted to the server, it must be checked against those conditions.

Side note: I'm not a big fan of restrictive "password strength" conditions and I don't recommend them. However, I do see the benefit of checking for a minimum length and making sure that the password doesn't exist in a dictionary or wordlist.


Are there any two way + two factor authentication systems in use?

This seems good except that it is vulnerable to a phishing attempt / rouge site that can get me to enter the OTP & then use it on the fly to get access.

This is what x.509/TLS certificate is supposed to prevent. If:

you trust the underlying mathematics of x.509 certificate and TLS,
both the server and the client has implemented TLS correctly,
the client machine trusts the server's CA (i.e. the CA's root certificate is in the client's trust store),
you trust your browser vendor's CA vetting process (or you have audited the trust store) and you trust the CA certificate issuance process,
you trust your browser to validate the certificate, such as checking the certificate's CN/, expiry, revocation list, etc,
you trust that the server have implemented precautions to control against its private key being misused,
you believe that the domain name belongs to the organization that you want to communicate with,
the server passes the TLS handshake,

then you can be confident that the server on the other end is who you think it is.

In any case, if the machine that runs the client you're connecting from is compromised, you're screwed anyway since you'll be entering both your credentials and OTP using the machine.


How safe is my login system (conceptually)?

Using a QR code in the process you described basically just ensures that the user has a cell phone, if I understand it right. So, yes, your suspicion is correct.

The way that apps like Google Authenticator are used is that the QR code is generated one time, when the account is set up (or when the user chooses to enable 2FA). The QR code is a way of sharing a secret between an app on your phone and the backend server. Once the secret has been shared with the app, the QR code is not used again (unless you need to register another app with the 2FA system and keep both apps active).

From that point on, Google Authenticator will continually generate a new temporary code every minute based on that secret. The login process will present an entry point for the temporary code. When you enter a temporary code (during the time when it is valid), it proves that you have a device that knows the secret.

While we're at it, step one is a little goofy also. For starters, I'm not sure how you would rate-limit attempts. Would you do it based on IP address? One IP address can have many users. It would be annoying if I couldn't login for the next hour because my roommate just logged in.

Beyond that, it adds one more password. A passphrase is the same factor as a password. It adds security, a little bit, but is it enough to justify memorizing something else? Why not require the password to be longer instead?


Token based approach is what I consider the most effective way of preventing CSRF attacks. If implemented correctly, token based measure never fails. While the other methods depend totally on the browser which isn't in one's control and shouldn't be relied upon. For example, EDGE still allows spoofing referrer header on GET requests. Also, privacy concerned users might disable sending such headers altogether. This may break your application for such users.
These header based approaches are used specifically to reduce server overhead of storing and checking token for each user or for each page because you wouldn't have to store anything at all.
I could see many drawbacks of using Origin/Referrer header while there aren't any for token based approach.

And, implementing one is enough to prevent CSRF attacks. There's no use in implementing both.


Netgear WNDR4300 crashes when port scanned

I have a distinct suspicion of what the cause of your semi-crash might be. If it is so, it's kind-of bad news:

  SEC Consult Vulnerability Lab has discovered the flaw, which Ars
  Techinca refers to as “amateurish,” in a driver referred to as NetUSB.
  The driver, as its name suggests, is installed on routers to allow
  computers to access USB devices over a network.

  Sadly, the driver contains an error known as a buffer overflow, which
  can occur when a device sends its name to the router and it’s longer
  than 64 bytes. The researchers claim that the simple overflow can be
  used to crash the router, using denial of service of attacks, and even
  execute code remotely.

According to Ars Technica & the vulnerability testers who caught the bug, it's present in both WNDR v1 & WNDR v2. (The full list of routers believed to be affected is in that Gizmodo article.)

Now, to be clear this is just a suspicion; it's possible the unusual attack traffic (unusual to your router, at least) might just have coincidentally arrived about the time that your 2.4 network had its crash-like event. Without further log details of what was actually in the packets of the suspicious traffic, details that aren't going to be in a consumer-grade router's logs, it's perhaps impossible to say for sure.  If the suspicious traffic reoccurs and your router immediately suffers subsequent issues, obviously the cause could then be known with more certainty. (Or if you were to capture some of that future traffic with a packet sniffer like Wireshark.)

You can try the check-for-updates capability wherever in exists in the UI there and see if Netgear has released a firmware update that patches the flaw/s. Sometimes consumer-grade router makers will act responsibly and do so.  Sometimes.

On the plus side, I guess, if this is an attack the person or program that knocks out your router has a slight sense of humor, spoofing an IP address of Symantec as the attack source.

Edit:

Ars has some more technical details on the vulnerability. It's really, really stupid:

  This router-side driver listens to connections on TCP port 20005, and
  it's this driver that contains a major security flaw. SEC Consult
  Vulnerability Lab, which publicized the problem, discovered that the
  Linux driver contains a simple buffer overflow. As part of the
  communication between client and server, the client sends the name of
  the client computer; if this name is longer than 64 bytes, the buffer
  overflows. The company says that this overflow can be exploited to
  enable both denial of service (crashing the router) and remote code
  execution.

Ugh.

If this situation is one such DoS attack, is there anything you can actually do about any of this?  Well, the obvious things for me to tell you are to try (1) disabling the USB port feature in the router UI and (2) try getting the router to block WAN traffic on port 20005, which is how the remote code that triggers the buffer overflow gets to your router. (Very roughly speaking, in non-technical terms.) Which might be good advice, except:

  Netgear told SEC that even with NetUSB functionality disabled through
  the router's configuration UI, the driver is still loaded, and there
  is no ability either to disable it or to block access to port 20005 in
  the firewall.

Yikes.

So...I'm sort of out of ideas at the moment. Maybe someone else has other suggestions.  If this really is the result of the attack method described above...

Edit #2: Qualified my previous statement that this situation definitely is/was an example of an attack to exploit the vulnerability described in the answer.  It might well be, but that is still, as the Scots might say, not proven.


How can the Origin header be used for CSRF prevention if Firefox doesn't send it for same origin requests or requests from data URIs?

The Origin header on it's own is not always enough (it's only sent on POST and CORS requests, but what you have is a GET request), but the Referer and Origin headers usually is (I'll include an example where they aren't sufficient at the end).

By default, Firefox does send the Referer header for same-origin requests. This is in-part why OWASP recommends using both the Origin and Referer headers:

  To determine the source origin, we recommend using one of these two standard headers that almost all requests include one or both of:

  Origin Header
  Referer Header

If both headers are not present, which should be rare (your base64 case being one of them), you can then either choose to allow or deny it.

  If neither of these headers is present, which should be VERY rare, you can either accept or block the request. We recommend blocking, particularly if you aren't using a random CSRF token as your second check. You might want to log when this happens for a while and if you basically never see it, start blocking such requests.

As OWASP says though, there are cases where these headers may not be present, so it recommends using an additional check, of which it recommends using CSRF tokens, especially if you do not block when neither header is present and correct.

  checking headers is a reasonable first step in your CSRF defense, but since they aren't always present, its generally not considered a sufficient defense on its own.

When requiring headers isn't enough:

If the site allows for user-generated content, like posting an image, it can be possible to do request forgery from the same origin. A GET request could be as simple as adding the following img tag to a public posting.

<img src="/forum.php?whatever=parameters">

Additionally for a POST request, if a user could also inject an HTML form (say the site is smart enough to filter JavaScript, but not HTML forms), it could be possible to trick people into submitting it, also from the same origin. This would at-least require user interaction though.


How big is the risk, to enable scripting in the Web browser?

There is definitely a risk - scripting essentially allows execution of code on the browser.  The vulnerabilities range from reading your browser's history to installing malware to phishing your bank credentials - each of which can potentially cause you "harm" in some way.

However, given that most of today's web sites rely on scripting, there's a huge loss in turning scripting off, up to and including the site no longer showing up in your browser.  Turning off scripting also won't protect against other ways for bad things to happen to your computer, so the return for the inconvenience isn't incredibly high.

Probably the most common use of scripting is analytics, which allows the webmaster for that site to gain information about who is accessing which pages, thus potentially improving the flow of the site and the information presented.  However, the flip side of analytics is targeted advertising, which allows advertisers to follow users across multiple sites.

The majority of scripts on websites are "mostly" harmless, just like the majority of software that's available is "mostly" harmless.  Security folks focus on the malicious side of things, and continually re-learn that there's a trade-off between usability and security.

What I personally do is use Firefox with the add-ons NoScript and Ghostery.  Between those two - NoScript especially - the chance of having scripts injected into the page I'm viewing is greatly reduced.  I still expect to get pwned at some point, but the tools I have will do a reasonable job of keeping me aware of what's happening as long as I continue to pay attention.


Extract urls from obfuscated android malware

I am afraid there are more ways to obfuscate an URL than one can count. It's very easy to come with another method when your last one got flagged, so static analysis is not recommended.

If possible, run the app inside an emulator, log all external communication and compare with a whitelist of allowed sites. Static analysis will generate too much false-positives and false-negatives to be useful.


Is it safe to backup data (images, documents, videos, etc...) from a possibly infected computer?

The way you phrased your question implies a basic misunderstanding, or perhaps I’m being pedantic, so bare with me.

In general media devices like thumb drives are not themselves infected, rather it’s individual files on the media that may be infected.

  This ignores device firmware rewrites, but that is very low
  probability in most cases.

The crux of the risks are the files you are moving. They may contain the malware and placing them on another machine may transfer the malware to that machine.

With normal modern configurations, there should be no automatic running of code simply by plugging in the thumb drive, although you may get a pop up asking you to do so to which you should obviously decline.

The big risk is from the files. While there have been a few exploits that managed to leverage data content only such as images via flaws in readers, these are rare. The more common threat is executable files. The catch here is that it’s sometimes difficult to know what is executable. Many “Documents” such as MS Office or PDFs can contain executables. These are you primary vectors for malware transfer.

The thumb drive itself can be sufficiently cleaned up with a long format (not a quick format).