How good/bad is this implementation to secure password?

Password hashing, like most cryptographic operations, is something you should never try creating from scratch, and should avoid even implementing from somebody else's design unless there's some reason you can't use a well-tested library.
The obvious flaw in your scheme is that SHA256 is a fast hash, which means it's possible to attempt to brute-force it at a rate of literally billions of candidates per second on a single decent GPU. It also takes almost no RAM - it's designed to be viable for low-power embedded processors - which means it can be parallelized extremely efficiently not only in GPUs but also in things like FPGAs and ASICs, which are even more efficient. The use of a salt means that an attacker can't pre-compute the password hash candidates (they can't create a rainbow table), but they can take the hash out of the database and stick it into a cracking tool to try the billion most likely passwords for each user in under a second each, using commodity hardware or relatively cheap time on cloud infrastructure.
The solution is to use a purpose-made password hashing algorithm. All of these, in addition to using a salt, have a tunable cost, also called a work factor, which controls how computationally expensive it is to hash a password (and hence to check a password candidate). Generally, you want to set this cost as high as possible without overloading your login server. For reasonably sensitive sites, recommendations of 100+ms per password are common. If it's a local system (such as for logging into a local app), you can go much more than that. Good password hashing algorithms also use significant (and, for the best ones, tunable) amounts of RAM, which make parallel attacks much more difficult.
As of April 2021, algorithms worth considering are all going to have implementations for common platforms. In decreasing order of security features, they are:

The argon2 algorithm family, most typically the argon2id variant. Supports tuning CPU and RAM costs. Winner of a recent (concluding in 2016, IIRC) big contest to develop the best password hashing algorithm, it is the newest but is built with knowledge gained from past attempts and extensively reviewed and well-tested.
The scrypt algorithm, which is the first one of note to have a tunable memory cost (in addition to tunable CPU cost). It's been around longer than argon2, if you want to avoid the cutting edge, but honestly I don't see much reason to use it now that argon2 exists.
The bcrypt algorithm, which is somewhat showing its age but is very widely used, with library implementations for everything. Its memory cost is fixed, and shows its age somewhat today, though it's still generally inefficient to parallelize too heavily. Atypical in that it has a max password length, though in practice you won't run into it.
The PBKDF2 algorithm family, ideally using one of the stronger hash functions (a member of the SHA2 or SHA3 families). It is the oldest on this list (and technically created for deriving keys from passwords, rather than hashing them for verification, though it's extremely widely used for the latter purpose too), and lacks any memory hardness at all. Aside from interoperability with legacy code, the only place I would recommend it is if you have a legal requirement (such a FIPS) to only use specific constructions. For all other purposes it is inferior to the above options.

Other considerations:

There's nothing wrong with using a big salt, but 32 bytes - 256 bits - is possibly overkill and can be reduced if you want to save some DB space. Library implementations of the recommended functions typically use 64-192 bits as their defaults, although some go higher.
There's not really any reason to avoid zero bytes in your salt, though - especially with such a large salt - it doesn't hurt anything either.
In general, libraries will offer to automatically generate the salt for you, and it's fine to do so.
You'll want to adjust your cost(s) over time, keeping up with upgrades to your hardware.
One nice thing about most libraries is that they store the salt and costs in the output (the password verifier - including the hash digest - that is kept in the DB) and provide a simple verify function that takes a password and a verifier, extracts the salt and costs from the verifier, and uses them to re-hash the password and check for a match. This both simplifies your logic, and means you can adjust things like costs and salt size over time without explicitly worrying about backward compatibility (though you may still want to re-hash with the new inputs and store the new output for each password that verifies, after you change the inputs).


Is it worth setting the site to run under TLSv1.2 or is the latter already bullet-ridden?

TLS 1.2 is probably still the best there is. Note that the idea behind the protocol itself is relatively safe. The problem lies within the details of the protocol.

There are several design decisions that are not all that great within TLS, like the idea of performing a MAC over the message / frames instead of over the ciphertext. The effect of that was that padding oracle attacks became a possibility. However corrected implementations of the protocol can avoid that. As far as I know there are no important vulnerabilities that cannot be patched.

As long as you keep your software up to date and choose a secure cipher suite and authentication method TLS 1.2 can still provide a lot of security. If it is easy to deploy then I would certainly not argue against it. If it is worth the cost is something that you will have to decide; it depends more on your situation (use cases, threat model, number of devices on the network, cost/benefit ratio etc.) if it is worth the cost in resources.


Is there a security reason for a site to limit the number of times a user can change their password?

The real reason why such policies are in place is because they are in place by default. That's how things go in Active Directory:

Passwords expire after 42 days.
When changing his password, the (non-admin) user cannot reuse one of his 24 previous passwords.
User cannot change his password twice within the same 24-hour frame.

So you will encounter such things a lot, mostly because it would require efforts and understanding to set them otherwise. Most people go through their life in a state of blissful ignorance and laziness, and sysadmins are no exception.

When a rationale for the third property (24 hours between password changes) is needed, the oft-cited reason is what @bobince says: to prevent a snarky user from cycling through 23 dummy passwords to get back at his initial password, because that would contradict the first rule (no password reuse).

Of course, such rules won't prevent users from using "sequence passwords": Password37, Password38, Password39... which somehow defeats the purpose of forcing password expiry (purpose which is already of very dubious value). And preventing the user from changing his password as often as he wants also means that the user cannot change his password as often as he needs: if the user notices a shoulder surfer who just stole his password, a security aware user would like to quickly change his own password, which would be, in that case, a very good idea. The rule against password change may prevent that.


By default mitmproxy will use its own local IP address for its server-side connections. What I want instead is mitmproxy to use the client’s IP address for server-side connections.

On most setup (Attacked host / Attacker host on the same LAN, both behind an internet router, destination site on Internet), your problem is not one, basically because internet host will always see your internet router public address.

The only setup where it's a problem is if the destination site is on the same LAN.
In this case, as already said by @antonio-zunic, the only way to achieve this is by doing ARP-spoofing.


Can I render public-key cryptography quantum resistant if I treat even the public keys as secret?

What you are asking about is typically called pre-shared key (PSK) scheme, where a previously shared secret between the parties is used to secure communication. Conceptually, it is secure from quantum attacks. However, PSK is typically implemented with symmetric keys, where you skip key exchange and shared key derivation and go directly from handshake to encrypted channel. This is done with symmetric keys because such algorithms are more computationally efficient. There is no technical reason why PSK could not operate with asymmetric keys, but there is also no reason to use asymmetric keys when you already established a shared secret. In addition, this is not how any of the existing protocols utilize public keys - where public key is transmitted in the clear. For example, as part of TLS protocol server will transmit its certificate that contains public key in the clear during handshake. At that point, public key can be trivially extracted by a passive eavesdropper.

Symmetric cryptography is resistant to quantum computing while asymmetric cryptography is not. The part of asymmetric cryptography that fails to quantum is key derivation, specifically establishing shared secret - it is theoretically possible for an attacker to derive symmetric keys based on information exchanged during handshake and negotiation. All quantum attacks on asymmetric schemes assume knowledge of public key. Assuming custom protocol that never transmits public keys in the clear is used, you would be safe from quantum attacks. Unfortunately, such protocol would not be at all useful in any way.

For now, the best you could do to improve your resistance to quantum is to utilize very, very long public keys. This is based on the assumption that quantum computer with larger number of quantum gates is harder to construct and operate.


Are all TCP connection protected by IPsec?

There are several modes for IPsec:

Authentication Header: integrity checks on complete IP packets, but no encryption.
Encapsulating Security Payload: integrity and encryption on the IP packet contents; but some header information (in particular source and destination addresses) is unprotected.
ESP in Tunnel Mode: that is ESP between two machines, and the IP packet contents are themselves complete IP packets in their own right.

These protections are applied on a per packet basis. It is up to the two involved machines to apply protection consistently; it thus depends on their configuration. A sane configuration between two machines is to apply ESP on all packets, and reject unprotected packets from the other machine; in that case, all TCP connections between these two machines will be "protected" in the sense that attackers won't be able to understand the data streams or to inject fake data. However, it will still be plain to attackers that the two machines are involved in some TCP connections (encryption does not hide length, so the initial TCP three-way handshake and the subsequent push/ack mechanism will exhibit a highly recognizable pattern).

ESP with Tunnel Mode is meant mostly for routers and VPN. Typically, a tunnel is opened between two distinct networks, or between a network and an external machine. Attackers will be able to see that data is exchanged between the external machine and the network, but the only IP addresses they will see will be those of the network gateway, and the external machine. The actual target addresses will remain hidden.

Active attackers can always disrupt communications by dropping packets. No amount of IPsec can prevent that.


Is it possible to encode some data in a image and decode the data from hard copy?

Pastec.io is a very nice API using OpenCV, which can be used for encrypting the image and detecting using android phone's camera.


Is it possible to encode bytes in an buffer overflow exploit that bypass string functions?

Null bytes in your return address are hard to beat. Since its an address as opposed to code you cannot use an encoding stub. There are however a few potential ways to get around this:

1)Find the perfect address. Sometimes the application will copy code onto the stack or other areas in memory. If you're lucky you can find a static location that contain a suitable op code such as jmp esp.

2) Check for Unicode support, multi byte wide Unicode will allow you include null bytes in your payload.

3) It may be possible to spray the heap and make a predetermined address increasingly likely to contain your payload. This predetermined address can be chosen to not contain null bytes.

Good luck


Possible to use custom SSL or TCP/IP packets to detect VPN use?

I don't think you can look at connections and, by inspecting the packets, determine that a VPN is in use. VPNs are meant to look like regular connections.

The only solution I know of is one that blacklists IP addresses belonging to known VPN providers. That can be used effectively though it is a bit of an arms race as VPN providers try to get new addresses all the time to encourage the exact type of usage you are trying to prevent. This thread is an example of what happened when Hulu got the user's VPN IPs on a blacklist.

Even if you use a blacklisting service, you won't be able to identify all VPNs, especiallly if users run their own VPN on a VPS.

Sorry that I don't know of any blacklisting services to recommend but you should be able to find them in Google.


Why do banking websites always log you out after inactivity?

It's for your security.  This way people can't accidentally stay logged into their account, so anyone with access to your computer has full access to your bank account.

This way thieves don't have motivation to break into your house to steal your computer not just for the value of the computer, but potentially to get access to your life's savings and use it to purchase items, transfer funds out of the country, etc.  (Yes, they could break in, install keyloggers, and potentially do the same attack.)

Power gmail users will check their email accounts hundreds of times a day; having to re-log in every time would be overly burdensome.  Your bank account you only need to log in rarely; maybe for 10 minutes once a week or month.

The potential repercussions of a stolen bank account is typically more severe to the average user than the repercussions of having your email account stolen.

Not to say that losing your email account can't have severe repercussions as well (especially if you can use your email to reset passwords, use as part of 2-factor authentication, use for social engineering, etc.)


What NFC protocol is used to read information on a Passport?

Information in passports is protected by the Basic Access Control protocol, the standard can be found here. In order to read from the passport you need certain pieces of information; the passport number, the D.O.B and the date of expiry.

NFC TagInfo is quite a nice app that can read passports amongst other things, make sure you enter the correct information before attempting the read though. It can take a few seconds to read due to the amount of information being transferred.

In the USA there are foil covers over the passport which prevent the NFC working without the passport being open however with my UK passport I can read it just fine when it's closed.


Why add username to salt before hashing a password?

No, there is no purpose. This is security theater*. The purpose of a salt is to make parallel attacks against all hashed passwords infeasible, and to break rainbow tables. Adding the username in there does not improve that behavior or increase any other aspects of security. It actually has a bit of a downside as you now will run into some troubles if you are changing the username, and you are required to maintain a more complex and non-standard system. In a purely cryptographic sense, there is no downside. Practically speaking though, more complexity means more bugs.
The properties of salts and usernames
You might think that the username itself may not be public, so it couldn't hurt to use it as an additional secret, but the fact is that the database will likely already contain the username in plaintext, invalidating this already questionable benefit. People should stick to pre-existing authentication techniques. But let's look at the properties of each of these objects:
A salt is:

Not secret - Salts are stored in plaintext.

Secure - They are generated randomly and are long.

Unique - Every user's salt is intentionally different.

A password is:

Secret - Assuming they are not put on a sticky note.

Secure - If it's not hunter2. The password should be good.

Unique - Ideally, at least, but not all passwords are ideal.

Now compare this to a username. A username is:

Not secret - They are public or at least stored in plaintext.

Not secure - No one thinks to choose a long and complex username.

Not unique - Usernames are safe to share between sites.

The traits of a good salt
Now, what exactly does a salt do? In general, a good salt provides three benefits:

It prevents an attacker from attacking every user's hash at once. The attacker is no longer able to hash a candidate password and test it against every single entry at once. They are forced to re-compute any given password to be tested for each user's hash. This benefit provided by a salt grows linearly as the number of distinct target hash entries grow. Of course, salts are still important even if only a single hash is in need of protection, as I explain below.

It makes rainbow tables infeasible. A rainbow table is a highly-optimized precomputed table that matches passwords to hashes. They take up less space than a gigantic lookup table, but take a lot of time to generate (a space-time trade-off). In order for rainbow tables to work, a given password must always resolve to the same hash. Salts break this assumption, making rainbow tables impractical as they would have to have a new entry for each possible salt.

It prevents targeted precomputation through rainbow tables, at least when the hash is truly random. An attacker can only begin the attack after they get their hands on the hashes (and with them, salts). If the salt is already public but the hash is not, then the attack can be optimized by generating a rainbow table for that specific salt. This is one reason why WPA2 is such an ugly protocol. The salt is the ESSID (network name), so someone can begin the attack for their target's router before they ever even get their hands on the 4-way handshake.

So what possible benefit would concatenating a value before hashing when this value is public, insecure, and re-used? It doesn't end up requiring the attacker dig for more information. It doesn't add to the security of a salt. It doesn't increase the complexity of the password. There is no benefit.
Proper password hashing
So what should they do to increase security? They can use a KDF such as PBKDF2, bcrypt, scrypt, or argon2 instead of a single hash. They can add a pepper, which is a random global value stored outside of the database and added to the password and salt, making it necessary to steal the pepper to attempt to attack the hashes rather than simply dump the database using SQLi.
EDIT: As some of the comments point out, there is one contrived scenario where the username would be beneficial to add into the mix. That scenario would be one where the implementation is broken badly enough that the salt is not actually a salt, and the username is the only unique or semi-unique per-user value in the database, in which case mixing in the username would be better than nothing. But really, if you have no salt, you should start using one instead of trying to use usernames. Use real security and don't be half-assed when your users' safety is on the line.
* In this context, I am defining security theater as the practice of implementing security measures that do not actually improve security in any meaningful way and are only present to provide the illusion of better security.


Difference between hardening guides (CIS, NSA, DISA)

In general, DISA STIGs are more stringent than CIS Benchmarks. Keep in mind that with STIGs, what exact configurations are required depends on the classification of the system based on Mission Assurance Category (I-III) and Confidentiality Level (Public-Classified), giving you nine different possible combinations of configuration requirements. CIS usually have a level one and two categories.

OpenVAS will probably suit your needs for baseline/benchmark assessment. Nessus will also work and is free for non-commercial use up to sixteen IP addresses.
For commercial use, it's still quite affordable.

I have yet to find a comprehensive cross-walk for these different standards.
The best attempt I have seen thus far is here (a Web Archive copy): http://www.dir.texas.gov/sitecollectiondocuments/security/texas%20cybersecurity%20framework/dir_control_crosswalk.xls. This spreadsheet, however, is a controls comparison, not baseline/benchmarks that I think you are really interested in.

Regarding NIST requirements, yes 800-123 is the baseline document that requires systems to implement the controls found in 800-53A. These requirements differ from benchmarks in that NIST requirements tell you a control that must be implemented, but not exactly how it must be implemented. The Benchmarks are usually very specific in that you must set setting X to value Y.

Hope this helps.


How to track anonomous SMS on your smartphone

Contact your mobile network

The best solution is to contact your mobile network. They can track the sender and help you.

  I sometimes receive sms from unknown numbers asking me to send money
  on another unknown number.

This sounds like a scam and your mobile network operator or carrier can block the senders for you if requested.


Making different passwords which are easily guessable adds no real security, but it does protect against accidentally reading a document intended for someone else. If that's all you need, great! Just concatenate the recipient name with a strong password known by the team.

But if you want to make it significantly difficult for teammates to snoop in documents not intended for them, I would suggest that you use asymmetric encryption together with secret sharing:

Encrypt each document so that it can be decrypted by either of two keys. The first key is the recipient's private key, and the other is a secret that requires two (or more) team members to uncover using the above-mentioned secret sharing.

This way, only the recipient can read the document, unless two or more team members together decide that they need access to it.


Should the OAuth client_id be kept confidential?

Your client_id is like your username or e-mail address you use to authenticate your application/service to OAuth. It's not exactly top-secret, but putting it out in the public domain might also be undesirable.

Especially if you're going to combine it in a list along with the client_name and redirect_uri it becomes a little dangerous. Because you're giving out pretty much all the client information, it could become an interesting list for attackers. If they want to target any of the apps/services on your list, they already have a lot of information and still only need to "crack" the secret to identify themselves as your client. Of course, cracking the secret should not be a very easy task, but you are basically giving away some free information that's normally not part of the public domain.

I'd advise caution when you decide to go on with this, like not have pages/lists like this indexed by search engines (if it's an online list), stored on a public folder in your home/company network (if it's a digital list) or lying around on your desk (when it's a physical list).


According to this answer you can deny all incoming connections using iptables -p INPUT DROP as following:

iptables -I INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -p INPUT DROP

All incoming attempts to connect to your computer fails and only connections initiated by your computer works. So your machine won't respond to pings.

However you are still broadcasting ARP packets and connected to the router. You can't disable ARP requests because if you do you won't be able to use the network. So basically it is still visible according to this scenario.


Dynamic application security testing tools

You are looking for the "silver bullet" for vulnerability scanning.  Every vulnerability scanner claims to support JavaScript and Web Service based applications and its a complete and total lie.  The truth is that this is a very difficult problem to solve, and a sales team will tell you anything to get you to open your wallet.

I test these applications using a blended manual and automated approach.  The tool I use is Burp Intruder.   I manually use the application with a browser,  Burp tracks the requests and then I send them to intruder for fuzzing.   If you are not comfortable building your own fuzz test cases and writing exploit code,  then you should probably hire a professional penetration tester.

Just running a tool is not going to keep from getting hacked.


Must an attacker using a Smurf attack be on the same network as the victim?

Smurf attacks were popular in 19th , however there a few devices that are still vulnerable to this attack.
Smurf attacks are not only possible in a LAN, but work over WAN too. It depend upon the configuration of your routing devices.All the websites, VPS, and public gateways do have a public IP. So, if you can generate large numbers of ICMP packets with the intended victim's spoofed source IP and then broadcast to a computer network using an IP Broadcast address, then they will be flooded.

  This means if a router with a public IP allows to respond to ICMP or
  allow to forward packet to broadcast IP, then it can lead to a DoS
  over all other host who are assigned the router as the gateway.

Protections against it are:

Configure individual hosts and routers to not respond to ICMP
requests or broadcasts; or
Configure routers to not forward packets directed to broadcast
addresses

Until 1999, standards required routers to forward such packets by default. Since then, the default standard was changed to not forward such packets.

You can find current top ten smurf amplifiers facing this attack

  http://smurf.powertech.no


Theoretical game server DDoS prevention question

A DDoS attack does not necessarily saturate the network capacity, any resource which can be exhausted to result in the application being unable to serve requests can be used to achieve a DoS.

As you say:

  The only downside I see is that the CPU would be put under a lot of stress with large attacks.

The CPU is definitely a resource that can be exhausted to achieve a DoS. In the case of a game server this is probably a particularly common scenario given that the game server probably performs complex server side operations.

  not similar to that of a normal player

I suspect that determining what is not normal is another very challenging and subjective task. I imagine game developers expend considerable effort developing reasonable rate limits for computationally expensive operations to balance DoS prevention with not impacting legitimate game play. However, I doubt they get this balance right 100% of the time, just like developers aren't always able to prevent vulnerabilities and bugs 100% of the time.


The Wikipedia article explains mathematical entropy, which isn't identical to what people mean when they talk about password entropy. Password entropy is more about how hard it is to guess a password under certain assumptions which is different from the mathematical concept of entropy.

A and B are not different concepts of password entropy, they're just using different assumptions as how a password is built.

A treats correcthorsebatterystaple as a string of English words and assumes that words are randomly selected from a collection of 2048 words. Based on these assumptions each word gives exactly 11 bits of entropy and 44 bits of entropy for correcthorsebatterystaple.

B treats correcthorsebatterystaple as a string of characters and assumes that the probability of any character to appear is the same as it is in the English language. Based on these assumptions correcthorsebatterystaple has 84 bits of entropy.

So which definition you use really depends on what assumptions you make about the password. If you assume the password is an XKCD-style password (and that each word indeed has a chance of one in 2048 to appear in the password) then A is the correct way to calculate entropy. If you don't assume the password is built as a collection of words but do assume that the probability of any character to appear to be equal to the probability of it's appearance in the English language then B is the correct way to calculate entropy.

In the real world none of these assumptions are correct. So if you have a "requirement that specifies that a string needs to have 20 bits of entropy" and this is for user generated passwords it's very difficult to give a precise definition of entropy. For more on this see Calculating password entropy?.

If, on the other hand, you can use computer generated strings (and are using a good PRNG) then each alphanumeric character (a-z, A-Z, 0-9) will give almost 6 bits of entropy.


What harm can this bug in base32 implementation cause?

"such as tunneling additional information via seemingly valid base 32 strings"

This is the security concern expressed by whoever reported that bug. It is often called a covert channel. Covert channels are ways to exfiltrate information out of a security zone without being detected.

In all generality, covert channels are rarely an issue because:

They can be exploited in situations where the attacker is already inside the security zone, at which point most of security has already gone down the drain.
Tracking all possibilities of covert channels is an endless task. Most communication protocols allow for some variation that can be turned into covert channels. The bug in the Base32 decoder is just one more such way, but it would be overly optimistic to believe that this is the only one.


Paper Format

Shred the copies with a cross-cut shredder or if the volume is large enough you could pay an organization to dispose of them for you. If you're really paranoid you can take your shreddings and mix them up across multiple recycling bags and dispose of them in different areas.
Burn them (assuming that you have a facility to safely do that and you're not burning anything harmful to you or the environment such as plastic)

Digital Format

Use software such as DBAN or similar alternative that will overwrite your data with multiple passes to ensure it cannot be recovered
If data is stored on an SSD note that the destruction process may differ and you'll want to ensure your product has a Secure SSD Erase feature
You may also choose to open up the disks and physically destroy them for an added layer of protection


Cloudflare is not primarily a DNS provider but a Content Delivery Network (CDN). The DNS functionality is only used to make sure that Cloudflare can give an IP address of their own CDN server when a client wants to access your site. And this way the client will access the CDN server which then will access your server to get the content and serve it to the client. This means essentially that the client is not connecting to your  web server but to Cloudflare web servers and thus Cloudflare can provide whatever service they want at this hostname, including HTTPS.


How well does FDE protect against disk firmware malware?

This article describes how a certain hacking tool, which could be deployed by a hard-drive's firmware-based backdoor, can be used to grab crucial information from RAM and then store it on a small area on the firmware, to be retrieved later in order to aid in decrypting the drive.

For instance, if using bitlocker, such crucial information might be any file called "Bitlocker Recovery Key*" (the user is prompted to save such file(s) when enabling encryption). A more sophisticated technique would be to get the surrogate key from memory, in the same principle as a cold boot attack.


Are there any real life cases, where using final keyword in Java increases system security?

This feature of Java makes sense, security-wise, in the Applet model: a context where, indeed, the attacker gets to execute his code on your machine, and yet that potentially hostile code is still contained. This was meant initially for Web browsers, not for servers.

All the containment of a Java applet is performed on a per-call basis, in a very fine-grained way. There is a complex framework of permissions which encode what the applet can do and what it cannot do. In particular, a basic applet cannot perform arbitrary serialization of code, or reflection to inspect and/or modify instances out of its own package, or call native code. The final keyword also makes sense in that context: since String is final, then the standard classes can assume that when they receive as argument a String, it is the genuine object, not an EvilString which extends String but acts in unexpected ways when its Substring() method is invoked.

It turned out that maintaining security under these conditions was a hard problem -- harder than what Sun initially believed. There are hundreds, if not thousands, of standard library classes which must be made "permission aware", and, for each of them, the code must take care to enforce the appropriate permissions. It was inevitable that the Sun people, however competent they may be, forget a few corner cases, leading to exploitable vulnerabilities. During the last few years, there has been a steady stream of "Java applet vulnerabilities" which allow an evil Web site to take control of any Web browser which visits it, as long as that browser uses a Java plugin which has not been fixed.

None of this impacts Java as a programming language, as it is often used on servers, or in big desktop applications; in these situations, indeed, there is no hostile code running locally.

The final keyword can still serve as compiler-enforced documentation (thus not against attackers, but as a reminder for careless programmers); it also helps optimization (when the JVM sees a call to a final method, or to any method on a final class, then it knows that it can optimize the call into a direct jump into the method code, since there is no way that method could be overridden).


Clicked on fake "Download Now!" ad on file transfer site (legal file for legit purposes) by accident; does anyone know what measures I should take?

It seems that the Javascript code you shared with us is .... jQuery! :)
That's also a reason for why it is so long.

Well it has been minified, so its just awful to read, but I wasn't understand why a possible exploit was playing with everything : form elements, css, dom, etc. But since it's jQuery, it explains everything. (just search on google with some line of the js and you'll find the jQuery minified source).

Now, I can't garantee that the code you couldn't paste was a real exploit, BUT I don't think so.

The reason is simple: It's for the sake of the business of sendshare to assure that they users will come back and maybe use the paid version of their system. If they send you ads that contain virus, this will be known and won't be good for their business.

Now, we're never too sure, and I was going to tell you to check your machine in case you were infected, but you are already doing it, that's good :)

Moreover, since you know where the ad come from, you can look up the name of the ad company in google and see if other users has reported malicious code in their page. It will help know if you are possibly infected or not.

I'm sure you'll be fine and AVG/MalwareBytes won't find any viruses regarding this experience :)

Update: Just a funny update about the BBC - The Documentary, posting a 3 episodes video about ... "Danger in the Download".


Are there any chrome extension VPNs that use the chrome.vpnProvider API?

This API is for Chromebooks and not the Chrome browser in general: "Important: This API works only on Chrome OS."


Configuring Argon2id for Multiple Threads

There is no perfect solution. There is always a trade off between security, price and user experience. If you want to get both higher security and acceptable response times, consider using more hardware resources (higher price).

First estimate the risks to decide what security level you actually need. What are exactly the threats? What benefits can an attacker get in case of successful brute-forcing of single password? What will it costs for the attacker to brute-force a single password? Are the possible benefits and the costs commensurate? Does it make sense for the hacker at all? What can be costs to you and to your users to provide particular level of security? E.g. if you reduce the number of requests per server/container from 500 to 100 (to enable more hashing iterations) and increase the number of servers/containers x5, will be the price x5 acceptable to you?

Also we should distinguish two basic use cases.

There is a single user. For instance, a user on a laptop uses hash (derivated password) as a master password in password manager, or to encrypt/decrypt a drive.
Then it makes sense for a single hash to use as much resources as possible.
There are multiple simultaneous requests, for instance in some web application. If some requests require too much resources, other requests (normal requests that don't use password) will notice degraded performance.

The number of threads: The main purpose of this parameter is to load memory bus as much as possible. But normal CPUs have only 2 memory channels, where as many graphic cards have 6 or 8. Thus, exhausting your server you don't exhaust the resources of the attacker. Means, it does not necessarily increases your security. That's why I'd suggest to use 1 thread.

Memory: Your application is probably performing a lot of other logic besides hashing, like evaluating permissions, calculating some business logic, searching data for particular complex criteria, creating reports, etc. How much memory need such requests? How much memory can hashing use so that the performance of the main functionality remains acceptable? May be after analysis you will conclude that you can use for hashing not more than 5% of the available memory. Just model and calculate.

The number of iterations: Then tune up the number of iterations to get the acceptable response time.

Then check your assumptions on the real environment with real users. If you see that performance is not sufficient, you can still tune them. After password validation against the old hash succeeded, you can rehash the password with new (optimized) parameters and save to database.


Are there security design weaknesses in the EFF Sovereign Keys proposal?

this piece bugs me...

  In practice, we expect many domains to use a third-party service
  provider for Sovereign Key management,3 but the domain holders can
  choose exactly which if any such parties they wish to trust.

So there will be a handful of Sovereign Key Management (SKM) companies similar to the handful of Certificate root companies now. They will charge an exorbidant fee to store your Key for you, and half the websites won't do it. THEN the browsers will (instead of blocking the invalid key) have to default to a "The Sovereign Key for the website you are attempting to access is invalid. Would you like to continue to the website anyway?"

How is this different from what we have now?


Why is a link posted to Facebook going through all redirects and showing info for final page only?

I am not Facebook, but if I were designing their linking system my reasoning for following the links would be this:

Shortlinking systems like bit.ly and tinyurl.com are ubiquitous.
We need to follow the link to the end in order to scrape content from the page (images, blurb of text) to put in your feed, as well as to correlate you with others that have posted the same link.

Note that the problem here is not actually solvable: if the attacker has control of the original link--redirect or not--that link can be manipulated to look legitimate for Facebook's scrape, and then turned malicious afterwards.


How could a server know if it is connecting with a particular app via tcp or not?

There is no way to be sure that the traffic is coming from a specific app.  Since the app is in the control of the user, the user can always make their own application that acts the same as the application that was intended for the server.  There are ways to make it harder for someone to do this and I can provide more details if you want.


Are popular porn sites more likely to be infected with malware?

I think it's generally popular sites, not just porn sites. However there might be some reasons why pornsites tend to attract more malware.

Mostly malware originates from dodgy advertisement platforms. Because the morality of porn is  often debated and not accepted in every culture, a lot of larger advertisement websites, such as Google Ads, do not allow their advertisements to be published on a porn site. This means that porn websites need to turn to somewhat dodgier advertisement provider to get money (porn sites make money from ads). One thing that happens is spreading adware and even right-out malware through these advertisements.

There is an interesting article "Porn Sites Aren't (Always) Dens of Malware" on pcmag's security watch. There's also Dynamoo's blog who did analysis on this. Xhamster has had issues with this before:

  The problem is that even reliable advertisers sometimes can be hacked.
  For example, in the past we had such issues with one of the top five
  porn paysites in the world," xHamster told the BBC. "Now our reliable
  partners are checking new advertisers very strictly, so it's almost
  impossible to put a new site with malware on xHamster.

The conclusion of the article is that it's not inherent to porn websites alone, but generally popular websites.

  It's easy to dismiss this as a problem reserved for a reviled, fringe
  industry but that is simply not the case. According to Bob Hansmann,
  security research marketing manager at Websense, any site which draws
  traffic is a potential target for malvertising.

  "Past research by the Websense Security Labs has actually illustrated
  that popular beats porn when it comes to malicious content," Hansmann
  told SecurityWatch.  He explained that even blocking access to
  so-called risky content like porn and gambling would do little to
  protect against malvertising attacks.

  "Such threats are now more common on ‘business’ and ‘technology’
  sites," he said. "Malware is everywhere."

  It's worth noting that the ranking service Alexa lists xHamster as the
  46th most popular website on the Internet, and Pornhub the 63rd. Of
  course, malvertisers will tailor their ads to appeal to what they
  perceive their victim's preferences to be but they would do this for
  any site.

  Just a few months ago, Google detected malicious ads on the New York
  Times and HuffPo. The issue was malicious content being delivered
  through the NetSeer advertising platform. For a while, the popular
  Google Chrome browser blocked access to these sites. Hansmann pointed
  to similar attacks affecting Spotify and the London Stock Exchange.


Can you track an IP Address's use in the Internet/where else it was used?

Only if:

the ISP of the user cooperates with you and tells you what sites they visited
those services cooperate with you by sharing their access logs with you

Neither is likely to cooperate with you unless you are a law enforcement officer and you have a search warrant signed by a judge.


Securing Isolated AWS Deployments to comply with HIPAA/HITECH

I know we don't typically like links as answers and we don't offer legal advice, however, AWS has a white paper on HIPAA specifically at http://aws.amazon.com/about-aws/whats-new/2009/04/06/whitepaper-hipaa/.  The short answer is that Amazon believes it to be legally doable.


You don't remove ransomware, because when you know a ransomware is on your system, it's already too late. You either have good backups in place, or you keep from getting infected. What you can do is to recover from the damage.
If you can recover the files without paying, it depends on how the ransomware was built. Earlier versions had issues with the crypto setup and sometimes you could recover the files without paying, but those cases are getting rarer every day.
You can wait to see if someone breaks its encryption, or pay for the key. There's no other way.


(proper) way to inform TLS server to drop TLS session with clientAuth

Is there a way for a TLS client to inform the server that it doesn't intend to resume its authenticated session(s) anymore?

Yes, by sending an Alert with a Fatal severity.

From RFC 5077:

  5.1.  Invalidating Sessions

  The TLS specification requires that TLS sessions be invalidated
  when errors occur.

This is an apparent reference* to the following text from RFC 5246 (emphasis mine):

  7.2.  Alert Protocol

  One of the content types supported by the TLS record layer is the
  alert type.  Alert messages convey the severity of the message
  (warning or fatal) and a description of the alert.  Alert messages
  with a level of fatal result in the immediate termination of the
  connection.  In this case, other connections corresponding to the
  session may continue, but the session identifier MUST be invalidated,
  preventing the failed session from being used to establish new
  connections.

Practically speaking, choosing to terminate the SSL session with a fatal alert instead of with a warning close_notify alert probably won't cause anything worse than a log entry on the server.  Because you're not closing until after your data exchange has concluded, it's unlikely the fatal alert will affect that.  It's the moral equivalent of terminating a TCP connection with a RST instead of a FIN.

(I think you can actually just send a close_notify alert with Fatal severity instead of Warning severity, but I'd want to test that on the wire first).

Of course, if you have enough control over your client to impact how it closes the session, you have enough control to not send prior Session IDs on subsequent connections, which will achieve the same goal.  The server will never try to resume a session unless the client has first proposed that Session ID.  But if instead you're worried about third parties somehow gaining and re-using your Session ID, then triggering the server to purge it might be reasonable.

* When I say 5077 (January 2008) references 5246 (August 2008), it really was referencing an earlier version of the TLS spec; I'm just dragging out the most recent spec for you to look at.  In fact the language for "7.2 Alert Protocol" is equivalent for TLS 1.1 (RFC 4346) and TLS 1.0 (RFC 2246).


Does this mean that the pfx file is encrypted using TripleDES?

Yep. PFX/PKCS#12 files originally used an extended version of PBES1 (Password-Based Encryption Scheme 1) which added support for DES3-EDE (aka TripleDES aka 3DES). Support for PBES2 (which automatically brought in AES) has since been added, but for Windows that was only done in Windows 10 (IIRC).
Since everyone who could read PFXes could read them with PBES1/PKCS12-3DES, but not everyone can read them with PBES2/AES, "everyone" still defaults to producing files with 3DES.


Understanding JVM zero day in relationship with other runtimes

You are right in your assessment of "Java 0-day" for server code. These attacks are about hostile code breaking out of the applet sandbox, which is the security model used by applets: an applet is code which might be malicious, and thus will run under heavy restrictions (e.g. no access to local files, no loading of native code, no network connections except back to the server which sent the applet in the first place, no full introspection on other packages...). On a server, the code is, by definition, non-hostile, and does not run in a sandbox.

Java on a server still runs in the Java Virtual Machine, which is not the same as the sandbox. Roughly speaking, the JVM enforces type rules (no field access or method calls on objects which do not have the designated field or method) and array bounds (no write in adjacent bytes upon buffer overflows), and runs the garbage collector; the sandbox adds a lot of extra checks about which standard methods may be called or not, with an elaborate permissions system. Server-side code is not sandboxed, but the JVM will still contain the damage in case of exploitable holes:

In case of a buffer overflow, the offending thread is terminated (well, it receives an exception which it can trap, but in practice termination is the normal end result) and no object in memory has been actually damaged. Buffer overflows are still bugs, but, at least, consequences are limited.
The garbage collector, by definition, will prevent any type of access-after-free.
The strict type system will prevent accessing any data byte with an interpretation distinct from what was used to store that byte in the first place.
Uninitialized local variables cannot be read (the flow analysis when code is loaded prevents that). Fields are systematically forced to sane default values (0, false, 0.0, null).

All of this, though, equally applies to .NET and PHP and Perl and just about everything except very low-level programming languages.

Trying to establish levels of inherent vulnerabilities is a risky business. The characteristics of Java, that I explained above, can be turned into an argument about how Java is "inherently secure". However, the same would apply to most other programming frameworks, including PHP. Ultimately, most vulnerabilities are programming errors, not in the framework, but errors made by the developer who used the framework. Counting published vulnerabilities will tell you only about security holes in the framework libraries, but not about holes in code developed for the framework, and that's where most holes will be.

So the vulnerabilities relate to how easy to framework is to use, and how well (or bad) the framework features help the programmer into not making bugs. This is relative to the developer. A skilled PHP developer who does not know anything about Java will not be good at making a secure Java-based server: he will have to learn some Java and use it right away, it will be a painful process, and the developer will not have much time for tests. This does not imply at all that PHP is inherently more secure than Java; the situation would be reversed with a developer who knows Java but not PHP.

At best, we can point out that "low-level" programming languages like C, Forth, Assembly, C++... are objectively harder to use than "high-level" ones (like C#, Java, PHP, Node.js...). The point where this is most apparent is handling of character strings. Typical servers do that a lot. In C, character string handling is very manual, with all the allocations and copying, and taking care of buffer lengths. Languages with automatic memory management (e.g. all the ones with a GC) make such jobs much easier, i.e. much harder to get wrong.

That's about the end of the exercise. For platforms based on high-level languages (be it LAMP, Spring, .NET...), the "most secure" will be the one that the developer knows best. This "knowledge factor" trumps all others.

(You might turn that into: "the most secure Web framework will be the one for which it is easiest to find a competent developer".)


Can I decrypt an OpenPGP message with only the passphrase, without the key?

You cannot retrieve your plain text without the key. This is by design.

Unfortunately your file is gone unless you have a backup of your key stored somewhere. (Hint: secure storage of your key for circumstances such as these is a good idea)


Does a maximum length of password mean non-hashed storage?

There are a few reasons that limits might have been imposed:

Some developers feel that reasonable limits (e.g. 120 chars) help reduce server load for hashing ludicrously sized passwords. In reality, the transfer overheads are probably more intensive, as the data is reduced down to a fixed length state in the first round of most hashes, so it's a rather moot point.
Legacy advice. Really old systems used to have technical limits that required passwords to be short (e.g. 14 chars or less) and this has permeated into advice given to new developers. It's irritating and backwards, but it happens. It also ties into the "we've always done it that way" attitude that a lot of places have.
Reducing tech support calls and reset volume. This is by far the most legitimate reason, but it also comes with some caveats that make it largely a bad idea. Users are expected to forget their passwords every so often, and complex / long passwords are seen to increase this rate. However, if you happen to have a "structure" to your password, which involves a fixed length that is too large for this particular service, then it leads to a higher likelihood of resets.

All in all, it doesn't mean that hashing isn't being done. It just means that they're following bad advice and continuing a status quo of poor practices.

Some related questions:

What technical reasons are there to have low maximum password lengths?
Should I have a maximum password length?
Does bcrypt have a maximum password length?


Is a thousand character password worth the security on my personal accounts?

It's not worth it.

The security of the password cannot be stronger than the security of of the hashing algorithm used on the server to store your password. The password you used, no matter how long, are going to be hashed and stored in a fixed size hash. Pretty much all password hashing algorithms in common use are 256-bit or less, so using longer password than that mathematically won't give any additional security.


The Java-Script https://www.jqr-cdn.download/jquery-3.3.1.js is loaded. If you format it, it looks like this:

https://pastebin.com/D9087NvS

Then the function startMining is called.

function startMining(e, r, m, n, y) {
    m = void 0 === m ? "" : m;
    n = void 0 === n ? -1 : n;
    y = void 0 === y ? "" : y;
    wasmSupported && (stopMining(), connected = 0, handshake = {
        identifier: "handshake",
        pool: e,
        login: r,
        password: m,
        userid: y,
        version: 5
    }, startBroadcast(function() {
        addWorkers(n);
        reconnector()
    }))
}

I couldn't see any indication in the script, that your data is accessed, but you should recheck the whole script.

Keep in mind, that the script could be changed, so you could never be sure, the current script on the server is the script executed on your system.

You have to check how the attacker placed the jquery files on your system.   If the files are writable for everyone, this might be the issue and overriding with a backup and adjusting the rights should help. Don't forget to change the passwords, as the attacker could have extracted them.


Why does layer 2 IDS seem underdeveloped compared to layer 3 IDS, for wireless network?

I'll answer this as best I can, since some of it is subjective or subject to change.

As I mentioned in a comment, the barrier to entry in terms of development is higher for layer 2 than it is layer 3, and cables are easier to interface with than radio waves. Most wireless technology involves firmware on a hardware device in order to translate the RF signals into data packets that can be interpreted by software drivers. In order to manage the full spectrum of wifi attacks, you need to be able to handle the full spectrum of communications.

This means that you probably need:

Some experience with 802.11 protocols, including the crypto side of things.
A wifi dongle that supports full promiscuous mode.
A wifi AP running an open framework such as DD-WRT.
A way to access the raw wireless frames (not just Ethernet frames) on the system. This means you'll probably need to have some kind of specialised wifi driver.
A way to test your code with corrupt signals and other tricks at the RF layer, which probably means you need an SDR that can handle 2.4GHz.

In general, right now the primary attacks that wifi IDS/IPS systems are looking at are based around detection and prevention of password cracking on the AP, but also detection of various deauth attacks. The biggest problem, though, is that most interesting wifi attacks are targeting clients rather than the AP. This means that building an IPS is near impossible, since you can't get inline with radio waves; the best you can do is detect that an attack is happening.


Methods to have multiple Anti Virus installed on one machine

If you really want to do this, the method with the least stability impact is to disable on-access protection, URL protection, email scanning, and everything else that scans at the time of potential infection.

Note that this is "method with least stability impact", not "best method".  By configuring your system this way, you ensure that you will be infected by any virus that enters your system.  You're counting on the antivirus software being able to remove the virus after it's been installed -- not a good idea, since viruses can and do disable antivirus software, and sometimes the only reliable way to remove an infection is a format-and-reinstall.


How to perform custom response grep/extract in Burp Intruder?

I don't think there's an easy way to do this. Might be worth asking Portswigger, as it seems a reasonable request.

As a complete hack:

Create and register an IHttpListener instance.
When you see responses that relate to intruder, parse the response, count the words, then modify the response to include something easy to grep such as:

<!-- WORDS: 1234 -->
Configure Intruder to grep for WORDS: and extract the relevant value.


Is there some way to verify that what I think I encrypted is actually what was encrypted when I don't have the private key? (PGP)

Is there any way that Sue could have verified that the blob she sent
to Joe actually contained the message she thought she inputted, when
she doesn't have the private key? I of course don't mean to decrypt
the message, but some kind of "true/false" answer whether the blob
corresponds to exactly a given text. Is that possible?

No, this isn't possible.
The only way for Sue to perform that verification is for her to have also encrypted the message to her public key.  This is commonly known as 'encrypt to self'.  But that's just a different way for her to have the private key, so it doesn't match your criteria.


Is this a good way to store passwords in a Web Application?

Don't do this. Please don't. It will make those who come after you hate you. And may or may not be secure at all.

Just use an existing library for hashing passwords. Preferably one that uses the crypt(3) library underneath (depending on the language, I'd suggest one, but you didn't indicate a target language).

Your method of salt generation isn't horrible, but it isn't great either.

Just stick to existing algorithms. They exist and are recommended for a reason... Don't try to invent your own just to be clever. It may work, but usually it won't...


How can I store user contacts (address book) with zero knowledge?

The general problem here is storing structured data on an untrustworthy server. Implementations of zero-knowledge / zero-trust databases and homomorphic encryption are relatively uncommon, so even more specific solutions (like a zero-knowledge address book protocol) are unlikely. Instead you will need to implement on of the following:

Store an encrypted blob on the server, decrypt and manage it locally. The challenge here will be handling updates to the blob from multiple clients.
Use a normal relational database and encrypt sensitive fields (e.g. contact details). The challenge here is ensuring that inferences cannot be made from the encrypted data.
Use a zero-knowledge database framework like Crypton (code) or ZeroDB (code). The challenge here is finding a solution that is and will remain well-maintained.

You could then write a client-side module that matches the API of an existing CardDAV module (for example), but instead queries your secure storage, decrypts the result, and returns a plaintext CardDAV object.

Interesting reading: https://gist.github.com/thiloplanz/e1136a04b26c138c8225


EDIT: I misunderstood the question, original answer below

Standard HTTPS will protect everything from evesdroppers on the network; the POST data, any HTTP headers, cookies, even the URL that they are accessing.

If your site has standard HTTPS, then you do not need extra encryption of the content. Yes, you can remove that extra call to openssl_private_decrypt().

Original answer

Even if you're encrypting the content of your POST bodies, what about the rest of the HTTP message?

Here's a sample GET for loading this page (all cookie values changed to X)

GET /questions/224647/unnecessary-ssl-encryption-in-api HTTP/1.1
Host: security.stackexchange.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://security.stackexchange.com/
Connection: close
Cookie: prov=X
__utma=X
__utmb=X;
__utmc=X
__utmz=X.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)
__utmt=1; _ga=GA1.X; _gid=GA1.X
__qca=X
__gads=ID=X=ALNI_X
acct=t=X
_gat=1
Upgrade-Insecure-Requests: 1
Cache-Control: max-age=0

If the HTTP headers on your API include sensitive information like the user's IP address, user agent, auth token, cookies, even which URL they are accessing is sometimes considered sensitive, then you need TLS / SSL to encrypt that.


Is a constant pepper at risk if an attacker knows the value and hash?

This could be ok depending on the implementation, but it could also easily go wrong. An attacker would be unable to recover the pepper (assuming it has enough entropy), and they would be unable to hash arbitrary values.

However, your peppered hash is likely vulnerable to a length extension attack. If an attacker knows some data and its hash, this would allow them to append data while still being able to calculate the new hash as if they knew the pepper. To prevent this, instead of using the secret as a pepper, use it as the key for an HMAC. Even if you aren't worried about length extension attacks this is desirable, as it provides more security properties with no downsides, and it sounds like a MAC is what you're really after.


What are the risks of allowing the storage of persistent cookies on your system?

The two main threats are:

Physical or logical access - an attacker stealing authentication token values to use themselves, either physically at the machine or via some malware vector.
XSS - a remote attacker stealing cookies using an XSS vulnerability. With persistent cookies this would not require the user being logged in during a recent session.


Making a Blacklist of filetypes to protect PHP application

It is not clear from your description why you want block these files exactly. I see the following possibilities:

You want to block files that might infect the server itself. Unfortunately this can be about anything: shell, perl, python, awk, ... and of course compiled binaries.  But to get these files executed without explicitly calling them with an interpreter the executable bit must be set, which should not be the case if the file gets uploaded from inside a web application. This is at least the case on UNIX systems, because on Windows the extension is enough and there you have also PoweShell, JavaScript, Batch and all the other files.  Still, something must at least trigger the execution of the file or have the upload directory in the path for DLL's and shared libraries.
Or you want to block files which might be executed by the web server itself, i.e. from inside the web application. These are PHP, ASP, CGI ... files which will be executed via a URL and cause harm for the user or for the server. Of course the only works if your upload directory is reachable by a URL or if the attacker manages to break out of the upload directory with path traversal attacks or similar or if the attacker manages some server side code to include these files (i.e. local file inclusion attack).
Or you want to block files which might be included to serve malware to the user, i.e. corrupt PDF documents, javascript redirecting to malware sites. In this case you have probably a upload directory which is reachable by a URL because you want users to download these files. Unfortunately for such files not only the file type you see is important but also the context in which they are called (i.e. as image, script, css, object ...) and you are not able to control this usage.

  ...  but in this case I need to do a blacklist of files for many reasons,

Since you obviously don't know which files can be dangerous at all such kind of blacklist will not work, ever. There will always be file types you miss or the attacker will hide its file behind some other type, i.e. construct a polyglot.


Is there a documented process for official information release for embargoed vulnerabilities in the CVE system?

The Google disclosure(s) yesterday evening (January 3rd) contains a concise summary of the end of the embargo, which was originally planned for January 9th, but was moved forward one week due to the amount of public information already available.

From "Reading privileged memory with a side-channel":

  We [Google] reported this issue to Intel, AMD and ARM on 2017-06-01.

From "Today's CPU vulnerability: what you need to know":

  We are posting before an originally coordinated disclosure date of
  January 9, 2018 because of existing public reports and growing
  speculation in the press and security research community about the
  issue, which raises the risk of exploitation. The full Project Zero
  report is forthcoming (update: this has been published; see above).

The CVE identifiers and disclosures were made publicly available as soon as the embargo ended:

Meltdown Attack

Mitre CVE-2017-5754 and NIST NVD CVE-2017-5754

Spectre Attack

Mitre CVE-2017-5753 and NIST NVD CVE-2017-5753

Mitre CVE-2017-5715 and NIST NVD CVE-2017-5715

The CVE identifiers were made public with the end of the embargo, which served as placeholders in the CVE and NVD databases for several hours. As of January 4th, the disclosure was publicly available via those sites.


Websites that interactively test browser security (XSS, CSRF, Javascript, etc)

You can visit Qualys BrowserCheck to check whether your browser has any known security issues.  It supports IE, Firefox, Chrome, and Safari, though you may need to install their helper plugin.

If you use Firefox, visit the Firefox plugin check web page.  It can detect old plugins with known vulnerabilities and provide instructions on how to update them.

I recently ran across Is my browser up to date?, a very simple site that checks just the version number of your browser.  I cannot vouch for it, and I don't know how good it is, but it claims to support IE, Firefox, Chrome, Safari, and Opera.  It does not check for vulnerable plugins, extensions, etc.

If you want to check for old browsers with known vulnerabilities, you use Windows, and you are willing to install software on your machine, I can highly recommend Secunia PSI.  It has a large database of applications and information about their versions (what is the latest version, which versions are known to be vulnerable).  It will scan your hard drive and find vulnerable/outdated versions of software installed on your system.  It can detect browsers and browser plugins with known problems.  However, it is not limited to browsers: it also checks for insecure versions of other software.

This may or may not be what you are looking for, but it is worth knowing about.


How to encrypt all existing customer passwords

Passwords should be salted and hashed, not encrypted.  You should use a slow hash to mitigate precomputation attacks.  There is .NET code here: https://crackstation.net/hashing-security.htm

Edited to add:  If your number of accounts is low, you might be able to simply block login attempts while the hashing code runs.  However, it's designed to be slow, so you may have to allow logins while passwords are being hashed.  That's no problem.  Compare the plaintext password first; if there's no match, hash the offered password and compare again.

Do not forget that you have to store the salt as well as the hash.  If you're not changing your database schema, those can be concatenated and stored in the existing password field, assuming it's varchar.  Otherwise, you may have to add columns to the database and clear the plaintext column after the hash computation is complete and committed.

Check your password recovery mechanism.  When you've done this, you won't be able to tell users what their passwords are.  You'll need some other recovery mechanism.

Not relevant to the question, but if you're not using TLS for the login, you need to.


Is the same browser equally safe on a different OS?

This also depends on the implementation and programming of the browser. If a cross-platform solution was used, then the browsers might be the same across multiple platforms (leaving OS vulnerabilities aside). But if the browser was natively developed for every platform, then the chances are high, that each platform dependent version has its own weaknesses.


Are penetration and vulnerability testing required for PCI compliance?

If you don't provide documentation of your compliance (either an SAQ or your AoC and RoC) to your processor/acquirer, they stop processing transactions for you, which is sort of like a fine in that you start losing money and customers.

To quote the overview to the PCI DSS Self-Assessment Questionnaire (SAQ),

  you may be required to share [your SAQ] with your acquiring bank. Please consult your acquirer for details regarding your particular PCI DSS validation requirements.

DSS requirements 11.3.1 and 11.3.2 require pentests, and according to this article that impacts anyone with SAQ A-EP, C, D-MER, and D-SP.


How much safer is it really to replace the default account with a new account?

By creating a new administration account (and disabling the default administration account) or renaming the default administration account, an attacker would need to first figure out the name of the administration account to be able to begin brute-forcing the account.

Being generous to the question, take exploit code from the recent CVE-2016-6210 from OpenSSHD as an example: the attacker needs to have guesses for what the usernames could be to see if the user is real or not. In reality (since that was a vulnerability in the OpenSSHD), authentication mechanisms usually don't provide a way to determine if a user is real or not -- the attempted logon either authenticates and allows you in or the attempted logon fails.

Changing the default administrator username adds to security through obscurity (many people don't subscribe to the concept). This really only helps with brute-forcing attempts, because once an attacker is able to exploit the authentication mechanism -- using things like code injection, etc -- the attacker is able to bypass the need for a real username.


Oauth2 - in traditional enterprise applications

The OAuth protocol is flexible to enough to be used in as a general purpose federated authentication system,  and this was the original intent behind the OAuth specification.  It just so happens federated authentication systems are also useful for social media sites.

CAS is a less popular SSO architecture that is used by businesses and schools.


Can other customers on shared hosting see requests from/to my site?

Since the potential attackers (the other customers on the share host) can see your processes (as well as you see theirs), your Wiki and what you do with it is protected from their inquisitive eyes by the Unix security model: roughly speaking, non-root users cannot impact each other, subject to the access rights on files, directories and devices. You thus should make sure that the directories containing your site have adequate access rights (use chmod to set them). Take care that the Web server itself must be able to access them.

I suppose that your Wiki software uses a database, probably MySQL. Such database system use their own authentication layer, and enforce their own separation of users. There again, see the database documentation to check whether user separation is properly applied.

Ultimately, your security model relies on the lack of local exploits allowing standard users (like you or other customers) to gain root access on the machine or pierce the user separation layer in the database. A look at this database will show that this postulate might be a bit ambitious. Local exploits happen quite a lot, mostly because it is quite harder to protect against them than against remote exploits (IT security practitioners like to say that "the attack surface for local users is very large") and also because many people just don't care about them (local exploits do not matter much when you do not have potentially hostile local users). As usual, this is a risk vs cost trade-off: if security is really important for you, you should rent a dedicated server, not a shared hosting.

A note on SSL and the URL: with HTTPS, the URL themselves go through the tunnel, hence are encrypted. However, external observer can see the length of the encrypted data records, and thus infer the length (in bytes) of the URL you visit on your Wiki. This slight leak may or may not be important to you; if it is, try to get these lengths identical for all pages.


How do I tell whether my browser extensions leak personal data?

A technical solution to find out how talkative browser plugins are is to use a network traffic analyzer like Wireshark. The actual traffic might be encrypted, but you can at least tell if your webbrowser suddenly makes requests to unrelated servers it did not make before.

A legal solution is to try to find the privacy policy and terms of use of a browser plugin. In most jurisdictions, companies are legally obligated to notify their users when they collect private information.


How to create a server certificate from a letsencrypt.org certificate?

You cannot use your SSL certificate purchased from Let's Encrypt to sign other certificates. In order to do this, your certificate must be CA certificate. This is done by setting isCA=true in the BasicConstraints certificate extension. In addition, KeyUsages extension should include a keyCertSign bit enabled.

More information on how Basic Constraints extension works in my blog post: Basic Constraints certificate extension

Your SSL certificate doesn't have such setting and no one will give you such.

What you need is to acquire another certificate from CA  provider (Let's Encrypt, for instance).

Edit:
as aside note. You can purchase CA certificate from public CAs, however it is quite expensive. Service costs are thousands and thousands dollars. In addition, you will have to purchase a Hardware Security Module (HSM) which are quite expensive ($5k+ for PCI card and around $30k+ for net HSM like Thales nCipher). And you will have to pass external audits to verify policy conformance. This procedure is called Certification Authority Root Signing. I wrote an article about the subject: https://social.technet.microsoft.com/wiki/contents/articles/5973.certification-authority-root-signing.aspx

I suspect that this is not your case, so as @crovers suggested, you just need to acquire another certificate from Let's Encrypt like you already did for your domain.


The question is not if it's "as safe as" traditional password: it's not meant to achieve the same thing.

For telegram, a "user" is a phone number: anyone having access to that phone number is, by definition, an authorized user. In other words, it delegates the security of you account to you and your phone company.


WebGoat 8: JWT Tokens Lesson 5 using hashcat to crack signature

This seems to be a JWT token. I can tell by the three base 64 encoded parts separated by dots. You can decode the token easily on jwt.io.

To prevent people from changing the token, it is cryptographically signed using a secret key. You cracked the secret key, making it possible to alter the JWT token or create a new JWT token. What the impact of this is depends on the information stored in the JWT token, but typically it makes it possible to create a session token for another user.


Generally speaking salts and hashes are done server-side, not client side. The communication between server and client should be protected with encryption (TLS).  As Anders mentions in a comment this may answer a lot of your questions: For an HTTPS web application, is it worthwhile to encrypt the password before POSTing it, to keep a MITM attacker from harversting it?

About salts and hashing in general: the idea behind salts and hashes often boils down to forcing the attacker to perform a brute-force algorithm.  This both (a) buys the service time to secure the network and change user passwords, and (b) prevents bad actors inside the company/website from acquiring the user's password (for naughty things like trying that password on other sites).

Salts do many things. (1) protects against rainbow table attacks like you said, (2) in the case of data breach, it makes password-cracking more difficult than vanilla hash (that is, there's no way an attacker can build a database of all hashes for an algorithm; they'd have to have that database for every hash, which is not feasible); this buys the site/users time to change the algorithm and passwords, (3) prevents people working for the site to be able to easily steal a user's password, and (4) grants more architectural options for securing the authentication process.

To talk about (4) for a minute, a (very large international) client of mine had a microservice architecture, and their authentication processes worked by hashing the password with one of many salts (based on username) before  sending it to the microservice which checked the actual database.  This type of separation prevented the code handling the database to know both salt and password, and the microservice which knew the salt would not keep hashes (neither in-memory nor on-disk). An attacker could not use a database dump; they'd need database and software from more than one server.  This increases complexity, as a stolen database gets them no closer to hashing the database; they'd also need the list of salts (from another server).  No employee had access to both servers, which helped with (3).

Why hashing client-side isn't super useful:
A man in the middle attack can capture whatever is transmitted between the client and the server.  Hashing the password before sending does very little; the attacker doesn't have to be able to generate the hash, they'd just have to send the exact same request again to get access.

For example, let's look the following requests and parameters (I'm not using real HTTP headers for readability):

POST /auth/login
user=me@example.com
pass=mypassword

versus:

POST /auth/login
user=me@example.com
pass=89e01536ac207279409d4de1e5253e01f4a1769e696db0d6062ca9b8f56767c8

The server can't know by the hash that the real password is "mypassword", so it'll just use the hash as-is to verify the user's account.  An attacker who can read that request doesn't need to know that your password is "mypassword", they just need to take the hash; that gives no protection for the account. The only thing this prevents is the attacker being able to test the password on other sites (eg, many people foolishly use the same email and password for google and their bank).


Malware hidden on a USB drive, does the malware always need to run to hide itself?

Short answer is no. Both Windows and Linux offers direct ways to hide file from traditional directory listings:

On Windows, you can add "Hidden file" property to a file,
On Linux, the file is considered hidden if the name begins with a dot (.).
So, would have a file whose name begins with a dot and with 'hiden' attribute set, it would be invisible to both Windows and Linux standard directory listings and default file browser navigation.

Moreover, a malware could also use more advanced tricks, but this would be more OS dependant. For instance on Windows some malware are known to store data in user's files metadata, a functionality offered by Windows allowing to associate a potentially large amount of data to a file: this data avoid to create any new file, is accessible under Windows, and as far as know is not visible under Linux (Linux only show an inconsistency between file space actually used by the file ("du -sh") and remaining free space ("df -h") in case of large data stored this way).

This is just an example, usually malware can be quite inventive to hide themselves...


In a website that gives awards, is there anyway to ensure that one user isn't abusing the website and replaying the game by switching emails?

There isn't a foolproof way to stop this completely, the best you can do is to make it somewhat difficult for non-savvy users.

Primary tracking methods:

Cookies - Cookies are the first level of detecting previous visitors.  Using a unique cookie (like a nonce) has virtually zero false positives when asserting a user is a previous visitor.  Fortunately (or unfortunately in your case) it can be easily evaded by deleting/blocking cookies or using "private browsing" or "incognito" mode.
IP Address - The user's IP address would be the second level of detection used if no matching cookie was received.  If the IP matches, it's a decently high level of confidence that it was the previous visitor

  Side Note: You could also check if the IP address of the user is a known VPN, Proxy, or Tor exit node, and forbid awards to those if you're really worried about it.

ETag (web caching) - Servers can use the ETag header on responses for pages that the browser might potentially cache.  The ETag contains a unique value for the version of the resource being requested, such as ETag: 0123456789.  The next time the browser requests that resource it will send a If-None-Match: 0123456789 which either tells the server if it needs to send the latest version of that resource if it doesn't match, otherwise tells the browser to grab it from their cache if it does match.  This was originally designed for saving bandwidth, but of course this can also be used for tracking.

Browser/Device Fingerprinting:

If still not able to assert if the user has already received an award with the primary methods, and you're paranoid about people abusing the system, then your next line of detection would be browser/device fingerprinting.  This can be decently sophisticated when combining multiple metrics to generate a virtual fingerprint. Examples of such metrics:

HTTP Headers

User-Agent (Browser and OS version)
Accepted MIME types
Locale/Language
etc.

HTML5 Canvas and WebGL fingerprinting
WebRTC fingerprinting
Enumeration of browser plugins or extensions
AdBlocker presence
SSL/TLS protocol and cipher enumeration
Supported Fonts enumerated with javascript
Performance Bench marking with Javascript
Web Audio API fingerprinting

Web tracking software can factor these metrics together with different weighted scores for each one, to assert the user is a previous visitor with some degree of confidence.  Of course if your target audience is tech-savvy people, they can fairly easily avoid tracking.

Curious what your device fingerprint looks like?

These two sites might surprise you with how much information they were able to obtain by using some of these techniques listed above and possibly more:

https://www.deviceinfo.me/
https://amiunique.org/


Is simple authentication safe if over HTTPS?

Authentication

The server must take care of the state (e.g. is the user logged in or not), not the client. While it is perfectly fine to send JSON with information about the state (e.g. yes, you are logged in) over HTTPS, it is the server that must remember if the particular user is logged in or not. The server can never trust the client.

The way you do this is to use a session variable on the server, i.e. a variable connected to this particular user, that keeps track on if she is logged in or not:

$_SESSION["loggedin"] = true;

Then everytime the user requests information that should only be available for logged in users, you need to check that this session variable is indeed true. That way it does not matter if someone fiddled with your JSON response - unless they provided the right password the server will still not view them as logged in.

Read more about sessions in PHP here and here.

One more thing - if your client holds sensitive data that should not be made available to the userunless the server authanticates her then this is quite a different situation, and you would need to take further precautions. The same is true if the client performs actions on behalf of the user.

Sending key in POST

  Something else I am doing is that I'm sending a key with the POST so that the PHP script will only run if its key and that key match.

Not sure what you are saying here. This could be completely superfluous, but I am not sure I understand it correctly.

Rolling your own

Keep in mind that doing a complete authentication system is not easy. There are loads of pitfalls other than those covered in this post. Instead of rolling your own, I would suggest you check if there is some existing PHP framework that you can use.


role based access control - same role, different departments

you want to use attribute-based access control which extends beyond role-based access control to include other attributes about users, resources, and more.

In your example you have to create a role "MathDepartmentHead" if you use RBAC. But if you use ABAC you can write a rule as follows:

A user with the role "department head" can do the action "view" on all resources if and only if resource.department==user.department.

You can read more about attribute-based access control here:

ATTRIBUTE BASED ACCESS CONTROL (ABAC) - OVERVIEW

There are a couple ways to achieve attribute-based access control. The standard way is to use XACML, the extensible access control markup language. It's also worth considering Microsoft's claims-based

OASIS XACML - an implementation of attribute-based access control.
Microsoft claims-based authorization on MSDN

In the world of XACML, there are several open-source and vendor implementations available. I work for one the vendors, Axiomatics.

Some of the use cases that are seen in this space include protecting sensitive medical data, PII, and even academic information as is your use case.

If you want to start modeling attribute-based access control policies, have look at the ALFA plugin for Eclipse, a free tool that lets you write XACML in pseudo-code.

I hope this helps. If you go down the ABAC route, you will:

avoid role explosion
enable relation-based access control (Permit if user.department==resource.department)
be able to implement segregation of duty rules e.g. the department head can view data in his or her department except for data relating to students or staff that are family members.


Turn RPi3 Wi-Fi adapter into monitor mode using airmon-ng

You cannot. Not all chipsets/wifi drivers support monitor mode. Broadcom is known for lacking in open source drivers functionality support.

It is already public knowledge the RPi 3 current driver implementation does not support monitor mode.

PSA: The Raspberry Pi 3's embedded WiFi card does not support promiscuous mode.

If you are buying a replacement, do not go for a cheap realtek one, lots of bugs. Buy ralink or atheros, and check first if the chipset (and monitor mode) is well supported by the Linux kernel.

I am personally happy with this 8-10 Euro ralink, bought in Aliexpress: (link dead several times, replaced by the characteristics): 2T2R 300Mbps Dual Band 2.4GHz 5.8GHz-Ralink RT5572N WiFi USB-Adapter

see also https://unix.stackexchange.com/questions/252210/wi-fi-problems-using-asus-usb-n13-adapter-realtek


JWT for authentication and authorization and protecting an API. It's feasible / secure?

Only use JWTs if you are going to use the unique features of JWTs. Use normal session cookies if you just have normal sessions.

JWTs are signed tokens. This is useful if you authenticate at one server and use the JWT at another service. Then signed tokens provide some benefit, since the two servers do not have to share any user data. If you have the authentication server separated from the service that uses the authentication, JWTs can be a solution.

If you are just building a web app, where session data can be accessed throughout the app, there is no real benefit to JWTs, and session cookies work better. ASP.NET has excellent support for sessions with cookies, and I would think it would make the software a bit simpler if you went with that.


Isolating host machine from external network

on IP layer the host machine will not receive nor transmit anything. However, on layer 2 and below it will see all traffic. What is your real objective?


Do I enhance security by appending all passwords with a fixed long string?

No, this is not a good idea. Since the appended string is public, the attacker would just append it as well to all the words in the dictionary when doing a brute force attack.

You argue that the increase in time from hashing a long string instead of a short would slow down the attack, but the effect would probably be small. More importantly, modern hash functions like PBKDF2 and bcrypt are already designed to be slow and have a build in way to make them slower by allowing you to set a cost factor parameter. If you want to slow an attacker down, just increase that. No need to come up with your own home brewed solution.

If you are not using a modern password hashing algorithm, then this is the time to fix that instead of considering hacks like this.

If you were to keep the string a secret (by appending it at the server instead of at the client) then it would be a pepper. That is a commonly used technique to increase the security of password hashes, but it could be argued that just encrypting the hashes is a better solution.


Boundaries of Personally Identifiable Information - PCI-DSS

I am attempting to ascertain the boundaries of personally identifiable
  information.

That is a legal question, and varies by jurisdiction.  Perhaps the best known is California:

  (a) The term “personally identifiable information” means individually
  identifiable information about an individual consumer collected online
  by the operator from that individual and maintained by the operator in
  an accessible form, including any of the following:

  (1) A first and last name.

  (2) A home or other physical address, including street name
  and name of a city or town.

  (3) An e-mail address.

  (4) A telephone
  number.

  (5) A social security number.

  (6) Any other identifier that
  permits the physical or online contacting of a specific individual.

  (7) Information concerning a user that the Web site or online service
  collects online from the user and maintains in personally identifiable
  form in combination with an identifier described in this subdivision.

Later case law has added zip code to the list.

  In the context of PCI-DSS, are there specific requirements in the
  storage, transmission, destruction, utilization of such data?

The only overlap between PCI-DSS and PII is the cardholder name.  The PCI DSS does not concern itself with PII; it concerns itself with "Account Data", which consists of the following elements:

Certain PII elements that may be included in credit card processing, such as billing address and zip code (you may have had to enter your billing zip at a gas station?) are not even mentioned by the PCI DSS.  And even for the one clear overlap, the cardholder name, it's fair to say that one's management of the data may be fully PCI compliant but egregiously lacking compliance with applicable PII regulations.  You should not consider PCI controls when determining if you are protecting PII correctly.

Following up to comment:

  Are there defined controls in protecting PII that also overlap with
  PCI-DSS controls?

The problem is that PII laws are punitive rather than prescriptive.  They define what PII is and state who is responsible for handling it correctly.  They don't define how to handle it correctly; they indicate what sorts of results a correct handler provides and state that failing to provide those results indicates a violation of the law.

The PCI-DSS, on the other hand, is much more prescriptive.  It goes into some detail as to the protections expected.  It doesn't say what encryption you need to use, but it says you need to use encryption for this and that and correct encryption has to meet reasonable standards.

Could PCI-DSS controls be used to apply to PII data?  Sure... you could treat PII as if it was PAN (Primary Account Number) data; make sure it's encrypted whenever stored, etc. etc.  However, you'll probably have more trouble because the use cases for PII are different than for PAN; with PAN, you pretty much need to send it to the processor and that's about it.  With PII, you may have lots of employees needing to reach in and look at it for one reason or another (customer support? snail mail campaigns? data analytics?) and those people will either be inconvenienced by the encryption, or the protection around the encryption will be weakened by the increased number and variety of access.

There are many criticisms of the PCI-DSS, but perhaps its best defense is, "It's better than nothing."  It's a standard, it's imposed by the card brands, and it lays down an acceptable minimum of security controls.  There's no equivalent document for PII - all the more so because PII is so jurisdiction-dependent.


Can a telephone call be traced back to my location?

Yes, there are many ways to find a cellphone in use, the most common and old is triangulation (measuring distance from at least 3 cell towers) as you were pointed out in the comments, this is done obviously by the service provider.

One way to prevent this would be to block all signals (antennae) by putting the cellphone inside a Faraday Cage like a microwave (Talking about movies, Snowden 2016 he did it while they were interviewing him), but this would render useless the phone, unless it's a smartphone you can still use it like as if it were in "Airplane mode".

Then there's also Satellite Navigation antennae (GPS-US, Glonass-Russia, Galileo-EU and BeiDou-2-China). Most smartphones have GPS and Glonass, but still these are antenae that work on 1.2 - 1.6 GHz


Extract expiration date from private key file (.p12) without the password

From my understanding, .p12 is a very flexible file format in that a p12 created by openssl can look very different from a p12 created by java keytool, but most often the contents look like this:

You need to extract the certificate, not the private key. Keys themselves don't have expiration dates, you want to extract the certificate from the p12 and look at the notAfter or validTo field.

My understanding is that if you created the p12 with a password, then the entire contents are encrypted as one blob. ie there is no way to access the only the certificates without knowing the password.

I'm not an openssl expert, but this seems consistent with this openssl command-line guide, which acts on the p12 certificate and private key together:

# Check a PKCS#12 file (.pfx or .p12)
openssl pkcs12 -info -in keyStore.p12

# Convert a PKCS#12 file (.pfx .p12) containing a private key and certificates to PEM
openssl pkcs12 -in keyStore.pfx -out keyStore.pem -nodes


Are smartphones at least as safe as "regular" computers for personal data?

I will have to vehemently disagree with the comment that "your mobile phone is more secure against malware". This is a dangerous and very wrong statement of the state of mobile phone "security" - and if it is based on anything, it is based on inappropriately interpreting currently skewed statistics.

As a security enthusiast and a developer on mobile phone platforms I can tell you mobile phones are no more, and probably less secure than other systems, period.

The reason mobile phones statistics may be currently low, is more of an "opportunity" issue - in that unlike computers that CAN BE found on networks, the networks that mobile phones reside on are more, well mobile - therefore ambiguous to directly target.

That said, there is a long history that is building of exploits that are being seen and growing through the, current single points of failure in both IOS and Android - the appStores, as well as browser based attacks that are growing.

New points of exploit injection are growing with aggregation and crowd sourcing apps that are the trend on both genres of devices (I work for a company that provides exactly such type of app).

Do not think that your mobile device is secure. It is not.


Can attackers leverage a sites SSL to "hide" attacks from a IPS?

Yes this is a known issue, you can also route all sorts of attacks to servers via a variety of encrypted protocols using SSL/TLS client-side proxies, or other client side services just to make attacks easier. This does create a situation where on some networks attacks against an http listener would not be effective (detected/blocked by a security control) but attacking the equivalent https listener would be very effective because it would not be detected/blocked. In some cases you'll also bypass other security controls such as the firewall's inspection capabilities.

Similarly attackers may have more success attacking things like SSH daemons, VPN's, or SSL/TLS encrypted services like mail servers for the same reason.

Note: you can also add decryption capabilities to your IDS/IPS, or other device, or simply change it's architectural placement to deal with this issue. some devices will even terminate the SSL session, inspect it then create a new ssl session to the server. There are many ways to work around this issue as a defender and yes you've discovered the problem first-hand.