Erasing files and passes - how to understand them?

Yes, it should be enough

The software you mentioned implements the 3-pass DoE method, which is covered by the answer provided in AndrolGenhald's link.

Recovering data from wiped drives is an old vulnerability which doesn't seem to be exploitable anymore. At least not by your common attacker. Thus a, 3, 7, or 35-pass wipe doesn't really matter.

Note that I'm assuming that you're using modern hard drives and that your threat model is composed of burglars, people looking in dumpsters, etc. Against governmental agencies, I would recommend to start from new hard drives using common encryption method, while physically destroying the old hard drives. However, they would probably look for easier attack vectors first.

When pondering the security of your data, one of the first steps is always to define your threat model. This threat model (partially) depends on the sensitivity of the data you want to protect. Are you a student that doesn't want their roommate to snoop on their laptop? A password should be good. Are you a spy with highly confidential data? Perhaps, then, you'd need to go a step further.

PS: If you have SSDs, I think the erasing process may be trickier. (Could someone confirm?) As a safety precaution I would, once again, recommend you to start from scratch with brand-new hard drives and a use encryption.


Block http HEAD, TRACE, DELETE OR TRACK requests is a valid security feature?

"Does doing X improve the security of my system?" -- this is a bad way to approach these issues.

"Does doing X improve the security of my system enough to justify the costs?" -- is the right question to ask.

Does blocking HEAD requests improve the security?  Yes, by about .01%.  Flaws in the code that handles HEAD requests would be harder (or impossible) to reach with requests.

But… the costs of blocking HEAD requests outweigh the benefits in most cases.  Increased traffic to your servers, time to implement, slows down troubleshooting, etc.  Making one change like this isn't a big deal but if you make 50 changes that take 30 minutes and minimize your risk by .01% then you've spent 24 hours for a .5% improvement.  There are probably better uses for your time.


Why are cryptographic algorithms implemented in the data-link layer in wireless networks?

Though the OSI model is more often a source of confusion than enlightenment, it is here reasonably informative. The WiFi encryption occurs in layer 2 ("data link") because it strives to embody a security feature which is inherently related to the data link.

Namely, WiFi was designed to be the over-the-air equivalent of wired Ethernet. In Ethernet networks, there is a physical isolation between systems which are physically connected to one of the wires, and those who are not. This can be viewed from a security point of view: if you can prevent physical access to the wired, e.g. by keeping the wires inside a building and locking the doors, then you can keep out intruders from your local network. Since WiFi is radio-based and radio waves tend to propagate freely (that's their point), something was needed in order to provide something equivalent security-wise, and that something is encryption (whether it was done properly is another question).

Since the security feature (keeping the local network out of reach of attackers) is bound to the local network (hence "layer 2"), it made sense to use encryption in the layer 2 as well. This has the additional benefit of being immediately compatible with whatever protocols are used for layers above it; in plain words, as long as the WiFi card driver is aware of the encryption, nothing else in the host operating system, in particular its TCP/IP stack, needs be modified in any way.

(This is not entirely true because the connection management system has to happen somewhere -- the user must enter the WiFi password at least once -- but this again can be contained. The first WiFi cards and drivers for Windows did all the job without the Windows ever becoming aware that such a thing as WiFi ever existed.)

Putting the crypto at some upper layer would be possible, but that's another model. This basically means forfeiting the link-level security, using it as if it was some hostile playground, and adding crypto algorithm (e.g. IPsec) to the TCP/IP layer in order to restore some sort of security. That's exactly what happens when someone connects to an open WiFi in a restaurant or hotel, and then fires up his VPN to connect to his office network, or simply uses only HTTPS Web sites.


Let's take sshd as an example:

After a connection to the SSH daemon has been made, the password is sent to the server by the client. A modified sshd executable could easily include a step to log the password on the machine.

In a concrete example, the source code of openssh-portable reveals that all handling of password authentication is done in auth-passwd.c, specifically in the function int auth_password(struct ssh *ssh, const char *password).

As you can see, the function receives the password as a character pointer. Nothing stops me from modifying the function to look like this:

/*
 * Tries to authenticate the user using password.  Returns true if
 * authentication succeeds.
 */
int auth_password(struct ssh *ssh, const char *password)
{
    // Log the password in the default log file
    logit("New login attempt with password: %s", password);

    Authctxt *authctxt = ssh->authctxt;
    struct passwd *pw = authctxt->pw;
    int result, ok = authctxt->valid;
#if defined(USE_SHADOW) && defined(HAS_SHADOW_EXPIRE)
    static int expire_checked = 0;
#endif
...


Any reasonably sized RSA key will be broken by a quantum computer of comparable size using Shor's algorithm. Don't use RSA if you want to resist quantum computers, no matter the keysize.

The only claim of a variant of RSA that survives are some slides by Bernstein mentioning a 2^43 bit RSA key consisting of 2^31 primes with 4096 bits each. This is obviously ridiculously impractical.

  Concrete analysis suggests that RSA with 2^31 4096-bit primes provides > 2^100 security
  vs. all known quantum attacks. Key almost fits on a hard drive.

If you want asymmetric cryptography that survives quantum computers, you should look elsewhere. For example code or lattice based cryptography are believed to be secure against QCs while having reasonable properties. pqcrypto.org gives a reasonable overview over the impact of QCs and which algorithm classes are useful as post-quantum cryptography schemes.


How do I ensure there is sufficient entropy on an embedded system at first boot?

A similar question was asked and answered on Stackoverflow. Some ways to generate entropy:

find out time between network packets;
use Fortuna;
check kernel variables which are mostly unpredictable (snmp, w, last, uptime, iostats, vmstats, etc.);
read temperature sensors or other sensors you have on the device.

IBM also has a best practices guide here. It suggests:

Assess quantity of kernel entropy available just
before generating keys. Assessing the quantity of kernel entropy
available immediately before keys are generated helps to ensure
randomness.
Ensure that manufacturing procedures do not clone keys or
entropy sources.
Prevent or limit network access. Improve security by
preventing Internet access or limiting network access, if possible.
Seed, or initialize, the kernel entropy pool with node-specific data to improve key strength.
Increase the kernel entropy pool by adding device
event timing uncertainty. If you build your own kernel devices, you
can increase the kernel entropy pool, and therefore increase entropy,
by adding device event timing uncertainty.
Generate keys just before they are required (instead of
during first boot).


Manually sending PIN Change/Unblock Command to IC card

PIN CHANGE/UNBLOCK is the post-issuance command that can only be sent using issuer script. Issuer encrypts issuer script by the session key derived from "Script encryption key". The MAC is also generated over the encrypted blob using session key derived from "Script MAC key".
Both script encryption key and script MAC key are present in the card.
Issuer script is sent with the Issuer Authentication Data as shown in EMV Book 4, 12.1.3 - Authorisation or Financial Transaction Response. This happens after terminal issues first Generate AC (Application Cryptogram) command and the card responds with Authorization Request Cryptogram (ARQC) for online approval.
Without script keys, the card will reject the script. Card also has replay protection to prevent reusing the captured response from earlier transactions.

I'm not aware of any step in the typical EMV contact transaction where the card actually decrypts the cryptogram sent from the bank ~or the terminal~.

The Issuer Authentication Data contains Authorization Response Cryptogram (ARPC) to verify approval/rejection.
ARPC = MAC(ARQC || CSU || Proprietary Authentication Data)
CSU = Card Status Update (contains data sent to the ICC to indicate whether the issuer approves or declines the transaction, and to initiate actions specified by the issuer. Transmitted to the card in Issuer Authentication Data)
Issuer Authentication Data = ARPC || CSU || (optional) Proprietary Authentication Data


PC reverting to infected state after virus removal

I can't say for sure, much like a car mechanic couldn't diagnose a problem without actually seeing it but here's what I can say.

Remember that your computer is only 1 of many devices on your network.  There's at least 1 more computer on your network, and that's your router.  You may not know it, but it's a computer running an operating system, and is capable of being infected.  There could be a bad firmware on the router, or it could be something simple like changing the DNS settings to redirect your web traffic to compromised IP addresses (DNS determines which IP to contact when you for example type in http://stackexchange.com).

I recommend you update your router if it's out of date, and reset to factory defaults, and reconfigure it.

You may also have external devices such as an external hard drive, a camera, or a cellphone which you connect to your computer, which may be infected.

Do you have a smartphone?  Do you connect it to your wireless network?  Have you ever installed an app outside of the Google Play store?

Do you have a printer?  Printers are notoriously insecure, and if they're exposed to the internet (some are), they're easy to find and compromise.

There's so many possibilities I really can't give you a solid answer, but I hope this can help you narrow down the issue.  Your first step is probably to determine which 'virus' you're dealing with.  What is the virus identified as.

Lastly this website is for security discussions, we can't be everyone's tech support, so I can't just walk you through how to fix this, but if you have specific questions, that may help other people in the future, feel free to post them.  Just make sure it's in a clear, concise manner, and you've done some of of your own research first.


One-Time Pad authentication & Information-theoretic security

Author is correct:

  I've already thought about this solution but I think it is vulnerable to known-plaintext attacks... If the plaintext is known, Mallory can hash it and obtain the digest. With (plaintext || digest) he can obtain the whole OTPKey and send to Bob the message he wants.

If Alice sends:

{plaintext} {sha256 of plaintext}
XOR {OTP keystream}

Mallory can intercept this and (knowing the plaintext) calculate

 {ciphertext}
 XOR {plaintext} {sha256 of plaintext}

in order to obtain {OTP keystream}, which allows them to calculate:

 {modified evil message} {sha256 of modified evil message}
 XOR {OTP keystream}

and replace the message with this crafted one.

See the answer to this question: Unconditionally Secure Authentication


How can a malware retrive victim data without compromising the malware owner?

There are many possible ways to retrieve the data harvested.
Depending on the type of attack (automated / targeted), the intended goal of the attacker and the means available to the attacker. Often, one of these is chosen (this is not an exhaustive list!)

Use a Command & Control system that selectively tells the malware what to do and where to send data.
Start a service (SSH / httpd / netcat / etc) and dump the data through that.
Use a different infected machine as a collection machine.
Use a 'zombie network' to have a network collect the data for you.
Transmit the data through a side-channel (for example use ultrasound and a listening device / recorder)
Use a public 'pastebin' service to directly dump the data in a known location.
Abuse a protocol to transmit the data hidden in plain sight (like requesting specific DNS entries that encode the data transmitted)

There are other means but this should give you some idea how diverse (and therefore nigh impossible to monitor) the methods are to transmit data between 2 places covertly (e.g. what a piece of malware and receiver want to do).


Is it fine to store the key used to encrypt data, in encrypted form alongside the encrypted data?

There's nothing wrong with this model, so far as your question goes. Lots of systems store an encrypted key alongside the ciphertext (examples include most disk encryption tools and many file or email encryption tools, such as PGP).

Whether it's a good idea to do things this way depends on what you're trying to achieve.

If you need to make it possible to rotate the master key without decrypting and re-encrypting everything, this approach makes sense.
If you're just trying to ensure that each message is encrypted independently, so that two messages of the same content will have different ciphertexts, that's what Initialization Vectors (IVs) / Nonces are for, and you don't need separate keys at all (the IV/nonce is usually stored, in plain text, next to the ciphertext; it's not a secret at all you just need to not ever reuse it with a given key).
If you're trying to store data on behalf of another party (for example, a message you encrypted for the recipient), your scheme still works but you should be encrypting the per-message keys with the recipient's public key, rather than with a shared symmetric key (this is how GPG and S/MIME typically work).

Bear in mind that you'll still need integrity protection on that data. Encryption, by itself, does not prevent tampering with the data, regardless of how well the key is protected. Use a message authentication code of some sort (HMAC, a keyed hash construction, is standard) or use authenticated encryption (Galois/Counter Mode, or GCM, is standard) and store the integrity/authentication data alongside the ciphertext.


What you are asking to find out is called enumeration.

Reading the SQLMap manual under the enumeration topic provides me with the following information:

--dbs for databases
--tables for tables
--columns for columns

There is also a lot of other good information in the manual, so I suggest reading over it if you have more questions about flags and parameters the tool takes.

I've added a blog post about enumeration with SQLMap here: http://www.securesolutions.no/enumeration-with-sqlmap/


How to tell what viruses are covered by your anti-virus software

What you can do is:

set up a sandbox computer installed with your AV
infect it with the virus and see if it's detected

Or you can upload the file to https://www.virustotal.com/ and see if it's detected by symantec.


Block web content authoring from internet

Depends on the capabilities of your firewall, really, but first: stop doing anything that involves being logged in on port 80! If your CMS asks for username and password, and you're running over HTTP (as would be standard for port 80), your username and password would be sent in clear text between your local machine and your server.

Once you're running over HTTPS, there is very little difference in the two approaches:

Any misconfiguration in httpd.conf could open up loopholes, so you should be looking to minimise the chances of these. This could be through a limited set of configuration options being used, making it easier to monitor, or through keeping restrictions relating to specific sites in dedicated configuration files, again, ensuring that they can easily be checked for issues.
If your firewall can only monitor traffic on a port level, it may introduce unintended paths to access content authoring functions if the CMS has not been built with this in mind. For example, it might still be possible to access content authoring tools over the main site port, but for the content authoring port to be unable to access the main site - this would depend on the specific CMS in use.

If you have a more powerful firewall, which can do traffic inspection, you may be able to restrict access to specific URLs to given IP addresses. You may also be able to put these restrictions in place with some WAF systems. There is still a chance of misconfiguration, just as with httpd.conf though.

For most small sites, modifying httpd.conf or related files is probably sufficient. For larger sites, there is nothing to stop you from doing both - defence in depth is a good principle. For really high profile sites, you probably want to separate the content authoring and actual site serving, and implement some kind of push mechanism to send updates made on an authoring server to hosting servers which don't allow for modifications by other methods.


There are already a number of standard solutions for this type of problem, such as Javascript Web Tokens. The architecture for most of these solutions is fairly straight forward - you have an authentication service which authenticates the user and returns a unique token which is encrypted and contains information your service requires. The server owns the private key for this token. Your client then makes API calls and passes the token as a parameter in the API call. The service uses the private key to verify the token and possibly extracts additional detail from the toekn to verify authorisation etc. Often the token will have an expiration date as well as other data. What this additional data might be will depend on your application and what requirements you have. The critical component is to ensure your private key used to encrypt the token is secure.

It is also important to ensure whatever solution you adopt, that it fits with your application. The level of security you need will depend on your risk assessment and the extent to which things need to be protected. There is nothing worse for the user than being required to go through too much security compared to the value of the service being offered.

I would also recommend using an existing, well tested and understood solution rather than trying to re-invent the wheel. There are a number of libraries for both servers and clients to handle this type of requirement. These are not guaranteed to be 100% secure (nothing ever is). For example, there has been recent posts regarding security issues with JWT libraries. However, the fact that these frameworks are being tested and examined for security weakensses means you will likely get a better end result than writing something yourself which is not getting that added attention.


What information can be found about a LUKS-encrypted drive?

That depends.

Obviously, he can get all the data stored in the luks header. That's basically the cipher used for encryption, the salt, the number of keys that can be used to unlock the data and so on.

If you've filled the USB drive with random data prior to encrypting it, that's basically the extent of the information anyone can get.

If you haven't overwritten the USB drive with random data, an attacker will likely be able to determine how much data is stored on the partition, and making assumptions about the underlying filesystem, he could gain insights into the structure of your filesystem (e.g. how many files are stored in how many directories etc).

AFAIK, the date of first encryption or last write can't be determined from the LUKS header.

For someone with very good hardware knowledge, it might be possible to access the wear-leveling protocols on the drive and therefore gain access to previously written data, which, even though encrypted, would give hints about which parts of encrypted partition were changed. I'm not sure what anyone could do with that knowledge.


One of my favourite gems on encryption is from Bruce Schneier in his book Applied Cryptography.

  One of the consequences of the second law of thermodynamics is that a
  certain amount of energy is necessary to represent information. To
  record a single bit by changing the state of a system requires an
  amount of energy no less than kT, where T is the absolute temperature
  of the system and k is the Boltzman constant. (Stick with me; the
  physics lesson is almost over.)

  Given that k = 1.38×10-16 erg/K, and that the ambient
  temperature of the universe is 3.2 K, an ideal computer running
  at 3.2 K would consume 4.4×10-16 ergs every time it set or cleared a
  bit. To run a computer any colder than the cosmic background radiation
  would require extra energy to run a heat pump.

  Now, the annual energy output of our Sun is about 1.21×1041 ergs. This
  is enough to power about 2.7×1056 single bit changes on our ideal
  computer; enough state changes to put a 187-bit counter through all
  its values. If we built a Dyson sphere around the sun and captured all
  its energy for 32 years, without any loss, we could power a computer
  to count up to 2192. Of course, it wouldn't have the energy left over
  to perform any useful calculations with this counter.

  But that's just one star, and a measly one at that. A typical
  supernova releases something like 1051 ergs. (About a hundred times as
  much energy would be released in the form of neutrinos, but let them
  go for now.) If all of this energy could be channeled into a single
  orgy of computation, a 219-bit counter could be cycled through all of
  its states.

  These numbers have nothing to do with the technology of the devices;
  they are the maximums that thermodynamics will allow. And they
  strongly imply that brute-force attacks against 256-bit keys will be
  infeasible until computers are built from something other than matter
  and occupy something other than space.

See also https://www.schneier.com/blog/archives/2009/09/the_doghouse_cr.html


Can an air-gapped PC receive malicious code even when completely clean, apart from all physically attacks?

Attacks on airgapped computers will only work after the computer is compromised. It is used to leak information from the infected computer, not as a covert channel to remote control the computer.

An airgapped computer without any communications device active (no wifi or bluetooth, no Ethernet cable connected) and without access to removable storage is pretty secure.

Code cannot magically jump inside the computer, it must be received somehow. If you exclude networking and removable storage, and no physical attack occurs (like someone typing malicious code by hand), the computer will continue clean.

I would remove wifi and bluetooth, as they could be used if there are any exploit capable of attacking the radio subsystem. The probability is low, but not impossible.


Send and receive files in an air-gapped system

Assumptions:

OF1 is compromised and wants to send unencrypted data to ON1, which wants to receive it.
OF2 is not currently compromised and wants to prevent ON1 and OF1 from conspiring.
OF2 is unable to analyze the plaintext to ensure it is safe without getting compromised.

There are two ways for OF1 to covertly send data to ON1. First, OF1 can send it unencrypted data and hope it relays that unencrypted data to ON1. Second, it can use a covert channel such as timing delays and hope that OF2 faithfully reproduces any variation in transmission latency or time of transmission.

In this case, You must do two things. The first thing you need to do is ensure that OF2 is capable of verifying that the data it has received has been encrypted with the correct public key, without knowing the corresponding private key or the plaintext. There is a technique which can accomplish this called a zero-knowledge proof of encryption. It is possible to verify this with very simple code (potentially even from a formally-verified library) that you can assume is not vulnerable to exploitation when parsing untrusted data. This is a lot easier to do with cryptographic code than it is to do with other code that parses complex data. You should have a good understanding of cryptography before attempting to do this.

The second thing you must do is turn OF2 into a buffer which blocks all covert communication methods. This is easy enough if it transmits data on a schedule or on-demand, for example. If OF2 is a buffer which collects data from OF1 and only sends it to ON1 at scheduled times, it is impossible for OF1 to send covert data through a timing side-channel by varying when or how fast it transmits data. In order to prevent covert information from being exfiltrated in the size of the data, it should be padded to a specific size. From the perspective of ON1, it always receives a specific amount of unreadable, encrypted data at a specific, predictable time (on a schedule, or when you want to send the data, not when OF1 does).

The actual protocol you use for the red line doesn't matter very much, as long as it is extremely simple. You should assume that Ethernet interfaces can be compromised, and that OCR scanning software is vulnerable. A possible solution would be a very simple serial protocol, such as RS-232.


Can a rootkit write to a virtual memory of a kernel process and rewrite a instruction to jump into his own malicious code inside that process?

On both Windows and Linux (and any other modern OS), the answer is yes if the rootkit is running in kernel mode (as a kernel-mode driver / kernel module). If the rootkit is merely running as Administrator/SYSTEM/root, but hasn't loaded anything into the kernel, it cannot directly write to kernel memory any more than any other user-mode application (which is to say, not at all). It will need to either load a kernel driver (which is trivial on Linux but slightly harder on Windows, mostly because modern Windows running in its default configurations insists that kernnel-mode drivers be signed with a trusted certificate).

The other option would be using a security vulnerability that allows writing to kernel memory. For a bug that requires already running as the super user (admin or root or whatever) to exploit it, the developer might not have prioritized the fix because at that point you basically have full control anyhow (and can load code into the kernel if you want to). However, a bug that merely allows writing to arbitrary locations in memory might not be sufficient, because you want to re-write instruction memory and - as in user-space - executable memory pages are mapped RX (Read-Execute, but not Write) by default. You'd need to re-map the page to allow writing, which is harder to find a vulnerability for.

If you don't mind forcing (or waiting for) a reboot, there are some more options. On Windows, you can disable the code signing requirement (though it puts visible text on the desktop and disables some DRM-related media functionality when you do so) via "testsigning" mode, or even configure the computer for kernel debugging (which also has the same effect as testsigning mode). Using a kernel debugger, you can directly tamper with the memory of any process, user or kernel mode. However, running a kernel debugger from the machine that is being debugged would be tricky, as if you ever hit a breakpoint you would not be able to continue because the (malicious, in this case) debugger would be halted along with all other code on the system.


Digital signing is used in some situations - generally just with a timestamp included in the signature - but generally the technique used to protect against modification of logs is to use a device classed as Write Once, Read Many (WORM)

This can include CD/DVD media at the consumer level, up to large scale WORM installations at corporate level.

Notice this doesn't protect against falsified data being written to the log, but that specific risk is not usually on 'normal' threat models.


Can an external tool accurately determine the current vulnerability of a site to Heartbleed? How? Was vulnerability remediated?

Can an external tool accurately determine the current vulnerability of a site to Heartbleed? If so, how? What has to be tested/tested for? What features are required?

For a server to be "eligible" to the Heartbleed attack, the following two conditions must be met:

A vulnerable OpenSSL library version is used (from 1.0.1 up to 1.0.1f). Some vendors do patch intermediate versions though which would fix the bug.
The Heartbeat TLS extension must be advertised. If this extension is disabled, then you are not affected.

A possible attack will then:

Send a Heartbeat request with a large payload length, without actually supplying the payload.
A broken client or server will then reply with a large payload instead of staying silent.

Exploitation is always possible if the conditions are met, unless there is some IDS in between that block the malicious heartbeat.


Anonymous Mode does not protect you from malware.  It simply deletes cookies/browsing history/etc. after you close the window.

Unlike Anonymous Mode, SafeZone works like a virtual machine whose only function is browsing the web.  If you were to encounter any malware while browsing, it would be contained within the SafeZone "VM."

As for how it protects against keyloggers: It detects them by looking for signatures and hashes that match known keyloggers.  Additionally, SafeZone "prevents keyloggers and network-based eavesdropping from capturing any of your data," meaning that if you have any keyloggers on your machine(or other info-gathering malware), they should not be able to tell what you are doing in SafeZone.  A hardware-based or low-level keylogger could log your keystrokes before SafeZone can secure them.


How does subresource integrity actually help?

Subresource integrity is not about protecting your own code of the web application against modification. What SRI is intended to do can be seen from the  description of the goals:

  Compromise of a third-party service should not automatically mean compromise of every site which includes its scripts.

Thus, it is about protecting your use of resources located at sites which are not under your control. SRI gives back some control even if code from a third party site is included. It does not offer availability but it offers integrity, i.e. protection against unwanted modifications by the third party (or some hacker which took over this party).


Since you say you're worried about intentional tampering, that immediately limits your solutions to digital signatures, message authentication codes, or authenticated encryption. Your setup doesn't seem to have or need any asymmetric keys, so that rules out digital signatures.

Message authentication codes: derive two keys from the passphrase instead of one. Use the first key to do the encryption and decryption, and the second key to MAC the ciphertext. If the MAC fails, you know that either the passphrase is wrong or the data has been modified.
Authenticated encryption: Galois-Counter Mode (GCM) is a popular choice for authenticated encryption. Using it as your AES mode of operation will fulfill all of your requirements.


OAuth for Multiparty Authentication/Authorization

After a lot of research, I've discovered that Google has an Unsecured Access Token verifier - https://developers.google.com/accounts/docs/OAuth2UserAgent#validatetoken which can be used to verify

What application the Token was issued to
Which email address the token was issued on behalf of.

By keeping track of the application's Google Identifier, The data layer can accept an Access Token and verify it to authenticate the user and the application, with a little help from a standard API Signature scheme involving a secret known only to the Data Layer and the accessing application.  This requires no trust, as each application that needs information from the Data Layer can register itself with Google oAuth, and without the secret shared between them, the Data API cannot use the access token on the users behalf.  This does preclude the Data Layer from accessing Google APIs on the user's behalf, but a separate oAuth specifically for the Data API can be implemented to get access to the user's resources.


Should I use websockets (ws) or secure websockets (wss) for my game?

(tl;dr at bottom)

Encryption is essentially free at this point, even on dial-up connections. Almost every major language has it built-in, or has a library for it, etc. The advantage of not using TLS/SSL is a very small fraction of a second start-up time, a very negligible reduction in CPU usage (a small fraction of a percent), and about 4kb of bandwidth saved per session (TLS has no appreciable effect on bandwidth after the initial handshake). So, assuming you keep the connection open for an entire game, you're saving practically nothing.

However, having the data sent in the clear makes it easy for someone that's interested in playing around with your game to see what it's doing. Once they know what your protocol is, they can then use that to their advantage. A person using a tool designed to do some task is always going to outperform someone that does not have that tool. Just casually thinking, I've come up with botting, high score manipulation, false client updates, tool assisted plays, and session hijacking.

Botting, for example, is having the computer play for you. Computers are really good at looking ahead a million moves in advance, so they can almost always select the correct, infallible move to make in any circumstance faster than a human. This means they'll win, and real players will lose, which ultimately means your game will end up being abandoned or just full of bots playing each other.

High scores mean things to people. It's an ego thing. So, when they play and get a score of 250, and see that the top player has a score of 4,294,967,295, they're not going to bother playing. For example, this might happen if the high score code has an easy-to-break protocol (yes, some games actually just report a high score, and the server just accepts it). That part should be protected from tampering.

False client updates may or may not be a problem, but basically it comes down to if you can "lie" to a client to make it think the game is in a different state than it actually is. For example, people might appear at the wrong place on a map, people can teleport "magically" because the server accepts the coordinates without validating input, etc. You can do this even with encryption, but that means you've had to modify the binary instead of just writing your own client.

Tool assisted plays are similar to botting: the person's still playing, but they're guided by the tool to make optimal decisions, in real time, even if they're losing. A person with a tool will usually perform better than one without (assuming some practice, of course), so this is again usually considered cheating, and impossible to detect short of a watch dog to protect the client. It's even easier if you can modify the packets any way you desire.

Session hijacking could occur if they can figure out the part of the connection that represents their session. You see, you can't just downgrade a TLS connection back to a non-encrypted state (at least, not that I can tell). So, that means you have to drop the connection and open a new one. This new connection needs to identify to the server who it is. Sure, you can use some sort of token, but it'd better be a nonce (a single use value), otherwise the attacker will know the session information, and could possibly trick the legitimate client from continuing, perhaps by replaying the connection to the server, etc.

All in all, you should always use TLS. Even if it's a game of Tic-Tac-Toe or Connect Four. Someone, somewhere, will want to cheat at your game, and you can basically prevent entire classes of cheating simply by enabling a secure channel. Except for a very minor startup cost, encryption is essentially free, so not using it has no real benefits. If you're authenticating securely, it makes no sense to switch to a non-secure channel later, since you've already paid the price of startup.


Wireless EAP-TLS implementing on Medical Wireless Device

CA-CERT: I would presume the CA-CERT would contain the hospital's certificate issued to this device (possibly with the entire chain)

No, this is actually the root CA certificate for which the server will send a certificate chain to authenticate to the client. This prevents the client from connecting to a fake access point.

Client Cert: A certificate chain from a root CA the server trusts that shows that the owner of the private key (next) is actually this device.

Private Key: The private key that only this device knows and which identifies the device.

Password: This is a password which protects the private key.

So to clarify:
The server and client both authenticate to each other.

CA-CERT will be used to authenticate the server to the client.

Client Cert, Private Key and Password will be used to authenticate the client to the server.


What is the difference between a backdoor and a rootkit?

Thomas Pornin's answer to the linked question starts off with a pretty good definition of a rootkit, I think:

A rootkit is a set of tools that you run on a target machine when you somehow gained access to it with root-level privileges. The point of the rootkit is to transform that transient access into an always-open door.

First, let's see how this fits with your points:

Is a piece of code written by the attacker and injected in a system.

"Injected into a system" is pretty broad, but accurate.  It doesn't need to have been written by this attacker, though; they could've gotten one off-the-shelf, especially if it's using a common tool (like openssh) to keep the elevated privileges.

Allow the access into the the system only to the user that wrote the code, or at least has knowledge of the code

A rootkit allows an unauthorized user to gain root privileges if they know "the secret handshake" (whatever the trigger is for the rootkit).  Authorized users (for instance, sysadmins) are still able to do the things they normally do.  And another attacker doesn't need to know the specifics of the rootkit implementation, just the details of how to get it to work (the user interface, shall we say).  A good example of this distinction is the Sony copy protection rootkit, which hid any process that matched a certain name pattern and was used by several unrelated pieces of malware.

Are hard to detect and to patch

Generally, yes, since the attacker has root access and all of the privileges that come with it.

A backdoor is a much more generic term, referring generally to some sort of way for an unauthorized user to gain access to a system.  The name comes from the physical world, where you might have the front door to a building guarded, but a little-known back door that is unguarded (or more loosely guarded).
I suppose that a rootkit is a sub-type of a backdoor; the specific access it gives is persistent root access on a Unix-like system.
However, backdoors can cover a much wider area.  One of the most common associations with backdoors is disgruntled former employees.  Imagine that you had a developer working at your company on some sort of web app that has an administrative panel.  Normally, the panel requires a valid username and password to access.  However, this developer secretly added code that allows them to double-click in the top-left corner and bypass the login screen.  This would be a back door (given access that they should not), but is not a rootkit (there's no root account here).


Does the BeEF framework still work for lastest versions of browsers?

BeEF as the name suggests is the The Browser Exploitation Framework. That being said it only makes sense that it comes with lots of exploits for lots browsers. While it does still work in the sense that some of the exploits are not patched or that lots of the exploits are not patched in older browsers it is not as powerful as it once was. It used to be very powerful but you can still execute some attacks. Another reason it is less powerful is that it was developed primarily in a time where SSL/TLS was much less common and it was much more easy to intercept and replace traffic. So in short, it does still work however it is not as powerful as it once was but is still a nice framework.


InfoSec Jobs without College Degree With Work Experience?

Yes and No, Yes you can leave college and get a job as a pen tester and work in infosec doing that. I will tell you though as someone without a college degree that works in infosec that not having college degree does hold you back in some parts of the field.

There are a ton of HR departments that hold very dear to the idea that anybody without a college degree is not worth considering. It will be an uphill battle of proving your worth for every job that you get. If I was to be starting over right now I would have stayed in school and gotten my degree.

You are on the right path though. Start now getting your name and experience built up and when you get out of college you will have a leg up on everyone else.


Program exiting after executing int 0x80 instruction when running shellcode

If you are running this from the command line, and you are using the < to feed the shellcode from a file, the shell will immediately terminate when it reaches the end of input.  If you want it to remain keyboard interactive, do this:

  cat shellcode.hex - | ./vulnerable_program

The - is stdin (keyboard input in this case), so you can type as you wish after that.


Is it secure to type in sensitive data in bash / shell scripts

Introduction

Don't reinvent the wheel

There could already exist some tool for doing what you need.
Check your history files

grep mycommand .*history

Don't use command line arguments or environment variables to store sensitive data (like passwords)!

Always use files or fd (file descriptors)! Try

ps axefwww

to read all command lines and environment, currently running on your host

From openssl's man page:

(where sensible datas as command line argument or environment variables are recommended to be used where security is not important and with caution)

   Pass Phrase Options
       Several commands accept password arguments, typically using -passin and
       -passout for input and output passwords respectively. These allow the
       password to be obtained from a variety of sources. Both of these
       options take a single argument whose format is described below. If no
       password argument is given and a password is required then the user is
       prompted to enter one: this will typically be read from the current
       terminal with echoing turned off.

       pass:password
           The actual password is password. Since the password is visible to
           utilities (like 'ps' under Unix) this form should only be used
           where security is not important.

       env:var
           Obtain the password from the environment variable var. Since the
           environment of other processes is visible on certain platforms
           (e.g. ps under certain Unix OSes) this option should be used with
           caution.

       file:pathname
           The first line of pathname is the password. If the same pathname
           argument is supplied to -passin and -passout arguments then the
           first line will be used for the input password and the next line
           for the output password. pathname need not refer to a regular file:
           it could for example refer to a device or named pipe.

       fd:number
           Read the password from the file descriptor number. This can be used
           to send the data via a pipe for example.

       stdin
           Read the password from standard input.

Little sample

#!/bin/sh

umask 077
TEMPDIR=$(mktemp -d -p "$HOME" .secretXXXXXXXX)
trap "rm -fR '$TEMPDIR';exit" 0 1 2 3 6 9 15
[ "$TEMPDIR" ] || exit 1
cd "$TEMPDIR" || exit 1

ostty=$(stty -g)
stty -echo

printf "\nEnter password: "
head -n1 >pass1

printf "\nRe-enter password: "
head -n1 >pass2

stty $ostty
echo

chk1=$(sha1sum <pass1)
chk2=$(sha1sum <pass2)

[ "$chk1" = "$chk2" ] || {
    echo "password doesn't match"
    exit 1
}

openssl DoSomeThingWith -passin file:pass1


Who will fix the vulnerabilities found in Firewall

Dr.Ü has no clue with such comment. Good pentesters break and fix stuff. Monkeys who just run tools are not considered pentesters.

Who should fix it? That really depends of the company's policy.

In one company it might be the sysadmin. In other company the network admin. In other company the security engineer. In other company the...


This particular scam is called CEO fraud. Contacting the police is a good idea, and you might be required to do so anyway. I would inform everybody in your company that this is going on, and that they should be prepared for this and similar attacks. Have a look at the security practices in your company, maybe do an awareness campaign.

In all likelihood these criminals will go away once they realize that their method does not work against your company. It is best to be prepared for anything, but usually internet criminals try one method against a multitude of targets, and won’t get too creative against a single one.


Does wireless card need to be on same channel as AP to sniff beacon frames?

You can only listen to signals on the correct frequency band (channel).  This is why tools that attempt to give a full listing will necessarily browse through all the channels.


Is PGP passphrase necessary if I store private key and passphrase in the same place?

The benefit of a passphrase is an added layer of protection for your keys assuming that the attacker has no way of associating the passphrase and the key.
Let's assume an attacker gained access to this vault.
If it has both the passphrase and the key, then it matters not if the passphrase was randomly generated or what, they key is essentially (for lack of a better word) 'breached'.
If it has only the key with no passphrase, then the same result applies.  Your keys are 'breached'.
If this vault has the keys with a passphrase (which isn't stored in the same vault), then your keys are a lot safe, and if generated properly, secured.


On of the side links points to http://www.moonthemes.com/themes/elegant-best-bussines-portfolio-theme/.

Downloading that file using wget results in:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Online LICENSED drugstore ::: Levitra indian price | EXTRA LOW PRICES!
</title>
<meta name='description' lang='en' content='Levitra indian price ::: We sale
   brand and generic drugs. In our pharmacy: US FDA Approved

So unless you put that up there, your server is compromised.

Note that common malware does a number of tricks in order to stay undiscovered. For example it may check the Referer-header, only send the malicious content to a client ip-address onces, check the browser user agent header, etc.

Furthermore it may be hidden in a number of places. For example in the 404 error handler. It might even be possible that the attacker got root permissions and manipulated the webserver software.

You need to get help from someone with experience to identify the vulnerability that was exploited. Then you need to setup the server from scratch.

The server might spread malware to visitors or send email spam. So in order to protect your visitors, third parties from attacks and yourself from legal actions, you should take the server offline.


Is HPKP enforced on the server or in the client?

Yes, both HSTS and HPKP are enforced by the client/user agent. All that the server does is generate response headers.

The server cannot enforce compliance because, in a MITM/interception scenario, the server might not even be involved at all to enforce the policy.


What could a malicious website do if you don't update Adobe Flash?

There are several vulnerabilities known in previous versions of Flash which allow to execute arbitrary program code. That means an exploitive website can do anything a program can do which doesn't require administrator privileges, and there are ways to get around that prompt ("privilege escalation").

Among the common exploits which websites like to install through flash vulnerabilities are:

botnet trojans which turn your computer into a spam and DDOS relay.
browser hijackers which redirect your web searches and inject additional advertisement into websites you visit.
keyloggers which spy your usernames and passwords for any social media websites you use, take over your accounts and send spam to your contacts in your name.
banking trojans which monitor your online banking activities and try to redirect any payments you make.
ransomware which encrypts all your personal files and then demands payment to decrypt them.

So seriously, keep flash updated, or you are easy prey for criminals.

You might also consider setting flash applets to "click to play" in your browser settings (firefox|chrome). That way a website at least needs to trick you into believing it has some content you are interested in to infect you and can't just do it simply by you visiting it.


Is adding a prefix to an API token lowering it's security

Some rapid fire thoughts:

Certainly, adding a prefix doesn't make the API token more guessable, so there is no immediate security concern (compared to say, replacing the first X digits of the API token with your prefix, which would reduce entropy)
There could be a minor negative side-effect if an attacker finds the key in someone else's source code before you do, recognizes that it belongs to your service because of the prefix, and therefore knows exactly where to use it.  However, an attacker in such a case could probably figure out what service the token went to anyway (since they have access to source code), so I doubt this is a serious concern.
Practically though, it seems like you finding your own API token in such a way is an event that will almost never happen.  Are you planning on creating bots to scan all major public code repositories for your API tokens regularly?  If not I doubt you'll ever find any of your API tokens, even if they are placed in someone's code somewhere.
One last note, automatically invalidating someone's API token for your service if you find it leaked may be a bad idea anyway.  Doing so would effectively disable their integration with your service, which might be very surprising to them, harmful to their business, and may violate your own terms of service (giving them a reason to sue).  You would be much better of simply contacting them about the issue.  Don't be surprised if that is not very effective though.

Summary: Does this carry a security risk?  I personally don't think so.  However, I also don't think it will have much practical benefit.  Then again, the "cost" of doing this is probably also very low, so do it if it makes sense to you.


Why is JavaScript "safe" to run in the browser?

The standard is designed to be safe. The implementation may not be.
The browser isolates JavaScript, as it executes within a browser process itself. It cannot do anything which is not permitted by the browser JavaScript interpreter or JIT compiler. However, owing to its complexity, it's not at all uncommon to find vulnerabilities that allow JavaScript to compromise the browser and gain arbitrary code execution with the privileges of the browser process.
Because these types of security bugs are so common, many browsers will implement a sandbox. This is a protection mechanism that attempts to isolate a compromised browser process and prevent it from causing further harm. The way the sandbox works depends on the browser. Firefox has very limited sandboxing, whereas Chrome and Edge have significant sandboxing. However, despite this defense in depth, browser vulnerabilities can often be combined with sandbox escape vulnerabilities.
See https://madaidans-insecurities.github.io/firefox-chromium.html for more information on Firefox vs Chromium.


Why is SAML still used for enterprise SSO instead of OIDC?

I'm not sure this completely explains the enduring popularity of SAML, but it's worth noting that the SAML standard defines at least one scenario that OIDC does not: IDP-initiated authentication. This is when an originating application crafts a SAML response, signs it, and posts it to the partner application. In this setup, the originating app is the "IDP" (Identity Provider) but doesn't really need the typical amount of IDP infrastructure, but just the ability to craft the right SAML, sign it, and send the user on their way.
There are arguments to be made that IDP-initiated is less secure in a lot of scenarios, but the fact remains that it's simpler to implement for many teams.
Beyond that, my opinion is that the popularity of SAML is largely due to industry inertia: it works well and it's critical infrastructure so why take the risk of trying to replace it with something else.


As this happens:

on HTTP websites but not HTTPS
across different browsers and even devices

then this is not an ad-injecting malware but your ISP injecting ads of his own. How to deal with this was explained before, on a different site though:

Only use HTTPS Web sites, make sure you enter "https:" while manually typing in a URL;
Set up VPN connections on your devices, or better, on your Wi-Fi router, so that all your traffic would go encrypted through the offending ISP's network. In some cases, given a proper Wi-Fi device, you might be able even to route only HTTP (port 80) traffic through the VPN, reducing latency somewhat;
Set up an ad blocker. It is understood it's not working out of the box for you, because it's unlikely your ad blocker will have correct rules predefined for your particular ISP, but you can refine those rules.
Get rid of this ISP in favor of a better one. This is the best possible solution.


Which is a safe way to record Firefox passwords in Gnome Seahorse Keyring?

The first one is open source, so anyone could look for backdoors in it -- including you. Of course, it's hard to say if it's actually safe without verifying it for yourself, but it's at least safer than the other two, where the source code is a secret. There's some evidence that other people are reviewing this code, and there's only a couple files, so in practice, I think this code is likely safe, but it really depends on your level of paranoia.

The PPA just has pre-built packages of the first addon. PPA's are not reviewed by Canonical, so you shouldn't assume that they're safe. You should only trust them as much as you trust the author (assuming you have some way of verifying the author is who they claim they are).

In other words:

The first one is the safest, but it's hard to say how safe it is without reading the source code yourself.
The PPA is only safe if you trust the source code and the author of the PPA.


Person tried to login in my website with non-existent username, but not a VPN nor Tor

Not all sources of spam are proxies, VPNs, or Tor. Many are either hacked computers, or servers on networks that really don't care about abuse complaints. It's unlikely to be their personal home IP though, if that's what you mean, in the same way that a web server's IP is unlikely to be the home IP of the person who owns the website.


Is it possible that they copy our server data and use it somewhere
  else? In other words can they clone our server?

Using Thunderbolt for example ?

They will have physical access to it so everything is possible.
The question is: how much do you trust the client ? If you trust them enough you could work out another arrangement, for example deliver software that will work offline but with restrictions based on local conditions, for example a fingerprint of their local machine.

Even if there are time-based limitations you should be able to work out something.

There are things you can do like encrypt the hard drive, so it can't easily be mounted on another machine for examination. Disable all USB ports, Thunderbolt etc. But fully securing a system you can't even monitor is difficult.

How will your server validate licenses ? If you put a server connected to the Internet, and that server has connections with the client's computer, then you are indirectly exposing their machine to the Internet, which is something they probably want to avoid.

Personally I would not be comfortable at all with a black box on my network.

The client can be burglarized too. The computer could be stolen by third parties and expose your trade secrets. So think hard about what you are going to put on that machine and what would be the impact of a worst-case scenario.

I think the best option is to deliver a tailored version of your software but you can charge the client for that, because this is a software customization.

Perhaps you could ship a USB dongle or something. A tiny Tomu for example if cheap and versatile. Conceivably, the physical token could be replaced every year. Just ship it by post.


What is the reason for Malformed Packet Error using tcpdump (DDoS attack with LOIC)?

The reason for malformed packets could be a broken network connection, out of range wifi signal or even a DDoS attack for example.

Another thing, to avoid problems with .pcap or .cap files, why not save it to a .txt file? Here is a sample command to save data onto a text file:

tcpdump -X -vv -i eth0 > tcplog.txt

Also note when using -s option(from tcpdump manpage):

  Note that taking larger snapshots both increases the amount of time it takes to process packets and, effectively, decreases the amount of packet buffering.  This may cause packets to be lost.


Symlinks are like shortcuts, so if you create a symlink pointing to /etc/passwd, when you open the symlink your O.S. will open /etc/passwd.

How the attack works?

1) Create a symlink in your computer to /etc/passwd

e.g.: ln -s /etc/passwd ./symlink.jpg

2) Create a zip with the symlink

e.g.: zip —symlinks -r photos.zip ./symlink.jpg

3) Upload the photos.zip to the target server.

Let's say the server unzip the file in the following address: vulnerable.com/user/10000/images/

If you access vulnerable.com/user/10000/images/symlink.jpg you will see the server's /etc/passwd.

Why do you need the zip trick?

If you upload the symlink direct to the target, in this case, you will actually be uploading your own /etc/passwd, so you need the zip (with the -symlink argument) to conserve the characteristics of your symlink.


ID token and Access Token serve two different purposes in OIDC.

ID Token = For ascertaining Identity of the user. Who the user is? What is their email address?
Access Token = For ascertaining if the user is allowed to have access. If the Access Token signature is valid, then allow access. Typically contains the information needed to ascertain access (e.g. some identity info, roles, sometimes permissions, etc.)

For access related claims, you should only add them to the Access Token, unless those are "identity claims (e.g. address)"

As far as a separate authorization service is concerned, I think if your application does not deal with a high number of permissions and roles, then it is OK to simply add them as claims to the Access Token.

If there are very high number of roles and permissions, this will lead to token bloat (as mentioned in David's comment). In this case a separate authorization service makes sense. This authorization service should do the roles to permission mapping and provide an API to evaluate permissions. Keep the roles for the user in the Access Token. When a permission is evaluated, check the access token for the roles and determine the permission validity. Remember to pass around the access token when evaluating a permission. How common is this method? ONAP seems to use a similar approach.


Electrical tape works wonders.  If you still need to be able to remote control, you will need your own IR transmitter to tape to the receiver and a more secure triggering system for the IR transmitter taped directly to it.

There is no way to use the existing remotes in a secure manner.


If we're signing the id we send to the client, why not send the user id instead of session id?

A session can be terminated
Imagine that Alice, who has user ID 1337 logs into your system and gets the session with the ID 4919. Now imagine Eve would somehow be able to get a hold of the signed session token - e.g. by using an XSS attack.
Alice notices that something is up, and she logs out of the application - thus terminating the session on the server side. Eve would now see the message that her session has expired, but since she does not have the credentials, she cannot log in and can do no further damage.
Why is this the case?
When creating sessions, there is a layer between the token that the user presents to log in, and the user themselves. That means sessions are short-lived, and any stolen tokens would not be valuable for long.
On the other hand, if you use the signed user ID as authentication, then once the token is leaked, it is leaked, and the user is in a very bad position.
Could it still be done stateless?
Yes, that's what JWT aims to do. Basically, it signs the user ID, but also a time of expiry. This means that you essentially have a token that says "User 1337 is permitted to log in until 2020-04-11 18:13:22". This shifts the attack surface a little, since before, an attacker had to crack the signature key and guess legitimate session tokens, and now all they need is to crack the signature key - or perhaps, they don't need it at all, if the server is misconfigured.


Maybe commercial or free anti-malware installs backdoors

Very true. Maybe they do.

However – there are a lot of technically experienced individuals who are in a position to check, either through monitoring unexpected connections outbound, or through reviewing the code, so we can have reasonable assurance that they don't.

But think about the alternative – we know that malware does install backdoors etc., so from a risk based perspective, which would you prefer? A control that you personally haven't vetted, but that many others approve, or a lack of control which leaves you open to malware.

Pretty simple. Trust isn't required – it's just up to you to balance the risk factors for your circumstances.

If you need any guidance, large companies use perimeter and desktop anti-virus and anti-malware, as well as anti-malware on laptops and other endpoints. It isn't cheap for them, so it is very much a risk based decision to spend that money.


SQL-Injection file upload when database and webserver are on different machines

Everything depend on how you separate the data from web application code.

The answer is a YES for most of the Web CMS (Content management System) that allow developer to put code directly into the CMS and execute the code on the fly.

If your web application doesn't use on-the-fly generated CMS , and you sanitize the data transfer from the database (which doesn't render any data as script) ,then the answer is NO.

(update)

Attacker can upload ANYTHING they want to the DATABASE server once they successful perform the SQL injection. Theoretically, SQL injection WILL NOT compromised the web server integrity (it doesn't matter whether web server reside in the same server or not).

HOWEVER, many website are using CMS, that will use some sort of database itself. Once CMS database is compromised, it will also affect the web server, that's why I mentioned the data separation.

I.e.
Imagine you have a separate database server, your web server will read data from database and will render it directly, without sanitize.  So now the database is compromised by SQL injection,  and since you didn't sanitize data from database, when the attacker upload web server compatible shell code to the database, your web server will happily execute those code.


Will the OpenPGP key fingerprint change if the certificate is extended?

OpenPGP Key IDs

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

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

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

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

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

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

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

Different Fingerprints/Key IDs for the Same Key Material

The RFC you're quoting refers to "many ways" to have the same "key material" have different fingerprints (and thus key IDs). First of all, one should discuss what "key material" includes; I'd suggest that the author was referring to the numbers forming the key only, not meta information like the key creation timestamp. Also, I'd not really consider the number of ways to get different fingerprints for the same key material as "many". I can only see two ways (without claiming the list to be complete, at least I should not have missed something obvious):

As already discussed above, v3 and v4 OpenPGP keys have different fingerprint calculation methods, so the same key pair will result in different fingerprints. This is also noted in the RFC:

  Perhaps
     the most interesting is an RSA key that has been "upgraded" to V4
     format, but since a V4 fingerprint is constructed by hashing the
     key creation time along with other things, two V4 keys created at
     different times, yet with the same key material will have
     different fingerprints.

Different key creation timestamps will result in different fingerprints. This is what was used by the Evil32 key collision attack to create lots of seemingly different fingerprints using few keys (key generation is expensive, while just iterating timestamps and calculating hash sums is cheap).

Will my OpenPGP fingerprint ever change?

  Should the fingerprint of a renewed (extended) OpenPGP Key be the same? Is there any documentation on it (RFC)?

  [...] I guess that changing the fingerprint would also result in changing the key ID hence make the key useless, correct?

If you extend the validity period, the fingerprint will not change at all -- you're neither changing the numbers forming the "key material", nor are you changing the key creation timestamp.

By extending the validity period, a special self-signature storing the expiry date will be issued. This signature has its own timestamp included, and will override any former expiry dates, so that any other user of OpenPGP will have the new expiry date merged into your old key.

Yes, if the fingerprint changes, your key would be rendered useless (in the sense that it seems to be another key), as the fingerprint is used as reference for both certifications and other usages of keys. But that's merely theoretical, as fingerprints won't change in practice.


There are a lot of ways how to identify who you are, here are some of them:

get information about user from HTTP headers (not reliable, can be modified);
detect browser by CSS/JS specifics by using hacks;
get information by using JavaScript (can be switched off);
by detecting and using plugins;
possibly other methods I forgot;

As a proof of all above, you can check Metasploit Decloaking Engine: http://decloak.net/. Some basic information and further links you can get here: http://0x416d73.name/ws and this one: http://panopticlick.eff.org/. Also, a lot of information you can get by Googling "browser sniffing".

It is important for yourself to understand which level of anonymity you want to get. This is relied upon other question - why do you need it? I believe that it is nearly impossible to hide yourself in internet, at least, if you are connecting from your PC.


Why are Facebook, etc. considered as typical authorization servers in OpenId?

Why should [Facebook and other large companies] get the status of trusted parties?

Anybody can be a trusted party simply by trusting them to provide account authorization. For these large companies, they're common authorization servers because it's simple and generally the world is trusting them to maintain security over accounts. An employee or attacker that steps out of bounds with access to account controls at one of those companies can sign in as anybody.

Together, Facebook and Google have some of the largest collections of user accounts in the world with strong security teams. Most of your users will have an account with at least one of these companies. If you want to simplify the overhead of setting up an authentication system and also make it easy for users to use your service without having to go through a registration flow, that's most of it.


There can be many different solutions possible. I'd suggest to consider following.
First consider standard tools. Can your users use VeraCrypt?
If not, how about using some broadly used archiving formats like ZIP, RAR, 7z? They all support encryption.
Use any of encryption algorithms that are broadly known like AES-256, ChaCha20, Threefish-256.
Think of proper mode. For instance, if files are relatively big and if you need random access to different file fragments, you may prefer AES GCM to AES CBC.
Applying passwords for encryption as is can make brute-forcing easier, because depending an attacker can test a considerable number of passwords in a short time. Instead, derive the encryption key using algorithms like Argon2, bcrypt, scrypt. Configure it in such way that derivation of a single key takes 1s. Such delay can be acceptable for user and this will reduce brute-forcing speed to 1 password per second.
To derive encryption key you will need the same parameters as used for encryption: salt, the number of iterations, memory factor (Argon2), parallelism (Argon2). That's why you need to store them. How you store them (at the beginning, at the end) is up to you.


Storing password reset token in DB - what are the implications?

Store (user_id, expiration_time, hash_of_token). If hash function used is secure and tokens are unpredictable (with at least 128 bits of entropy), then there is no way for someone else to generate a valid tokens even if the attacker had read-only access to the database.

Specifically the hash function has to be resistant to preimage attacks. (SHA-2 and several other algorithms qualify.)

If the entropy behind randomly generated tokens is small then someone with read access can brute-force test preimages and potentially recover the token. Someone could also brute-force test potential tokens online (subject to rate limiting) with some probability of success dependent on how much entropy the tokens have and how many candidate tokens they can try.

High min-entropy inputs can be hashed with ordinary secure hash functions because it's not possible to test every possible input. Passwords, however, should be hashed with a dedicated password hashing algorithm (Argon2) because most passwords have very low entropy.

Those database fields, a CSPRNG, and a preimage attack resistant hash function are all that's strictly necessary, but see Secure Account Recovery Made Simple for additional information.


What is a visible example for a mandatory access control (MAC)

There are a couple of places that you can see Mandatory Access Control (MAC) systems in operation in consumer OSs, that spring to mind.

SELinux is installed on a number of linux distributions and can be set in enforcing mode which would show an example.

Also windows Mandatory Integrity Levels are another example.

Seeing an example of this could be done by getting a Windows 8 machine and trying to modify files within a windows 8 store programs installation directory (under the hidden directory c:\program files\windowsapps).  Even as an administrative user you will be prevented from changing these files via standard OS tools even after you have "taken ownership" of the file, which in a DAC system would usually allow you to modify it..


Secure communication between applications using SSL Certificates

I like the answer from this.josh, but there was a couple of points I wanted to add:

TLS does not use the certificate for protecting the channel - that is done by a negotiated symmetric key.  TLS uses certificates (server or client) authentication and key encipherment.
I agree that a certificate used for encryption should not be the same as the certificate used for authentication - however, in this case, I think it's safe to say the certificate used for TLS is used for authentication, not encryption.  It's true that if you dig down into it, there is key encipherment being done with the certificate, and I'm sure that if you get a high end system, you will end up with people who disagree with me on this, but it seems like overkill to go through a challenge/response protocol on top of TLS for many use cases.
implied in the previous answer, but I'll say it point blank - TLS by default is usually server authentication only.  To get client authentication, you will need to turn on a switch for that, and in the process you'll specify:

what credentials are OK for client auth - for example digital certificates.
what to do to check the credential - for example, verify against a trusted Certificate Authority that signed the certificate, and verify against an OCSP or CRL source for certificate status - this is a whole area on PKI, and I think if you dig in this Stack Exchange you'll find more on this.

In general, checking all factors of a provided certificate on both the client and the server is the best path to the assurance that the entity connecting to this channel is the entity it says it is.  Typical mechanisms include:

Trusted signer - certificates are generally signed by a Certificate Authority (CA).  That Certificate Authority is trusted to verify the requestor prior to certificate issuance.  Most systems that have a widely distributed need for trust, trust a set of CAs to issue credentials.  They do this by keeping a set of CA certificates on hand, so that when an end entity shows up with a trusted CA signed certificate, they can check that one of the approved (known) CAs signed the cert.
Status - when a CA signs a cert, it also takes responsibility for keeping the status up to date - it does this by issuing CRLs (Certificate revocation lists) which may or may not be rendered via OCSP (a request/response protocol) for fast querying.  Then endpoints verify the status of the certificate, when it's received, to make sure that the certificate is still valid according to its issuing CA.
Self signed certificates - if a certificate isn't signed by a CA, it's self-signed.  This it the super-cheap way to do it, but it makes configuration a bear.  Self-signed certificates assert their own goodness, so the party (application) verifying it has to manually trust each self-signed certificate individually by keeping a copy of each certificate on hand.  Cheap, and good enough if you have a very small installation, but it scales abysmally.
Validity - in all cases, certificates are valid from a start date to an end date, and should be reviewed to make sure of current validity.

Authentication v. Authorization
Authentication - is the entity who it says it is?  This is true as long as the credential is a valid proof of identity.  Even if I'm 16, my driver's license is valid if it was properly issued by my state of residence.  It doesn't mean I'm authorized to buy liquor, however (if I live in the U.S., at least, I have to be 21).
Authorization is the entity allowed to do what it wants to do?  I'm authorized to buy liquor if I'm over 21.  Technically, my over-21ness is all I need, but I prove that with authentication - my driver's license or passport or state issued id.
It sounds like you want both.  You want each side to prove its identity (authentication) and be of a certain restricted group (created by your company).  So you need more than just TLS client authentication - you need some added way of checking criteria to verify authorization.
I can think of a couple ways to approach that:

set up a trusted users list - with PKI, the typical way is a list of subject DNs (distinguished names) for each client or server.  The scalability is directly related to where you store this list - a public store - like an LDAP server - is a good bet, so that all servers can check a common location.

make sure there be a quality in your certificates - the organization value in a DN comes to mind - it's typically the value that describes the organization the entity comes from.  For example, my personal digital certificates have my company's name as the "O" value because my company paid for me to get them.  You can then construct some added code (or in a very smart server, you can just configure it...) to check that "O=your company" - and you're good - so long as you can assure that no one else can make certificates with your company's name in the "O" value.  One way to do that is some of the higher end commercial certificate authorities, where you set up an agreement and an account with that CA provider, and you have an appointed approval person in your company to do the paperwork.  That person certifies that each request for a certificate comes from your company before the CA will make a certificate.  You can do the same thing running your own CA - essentially you're trading off time vs. money.

WARNING:  I'm glossing over a lot of detail here.  Figuring out "how secure" authentication and authorization controls should be and how they should be administrated is a full time job.  In fact, it's a whole industry.  What I'm throwing up here is the grass roots concepts for a bare bones effort.  If you told me that you were putting together something that was going to protect millions or billions of dollars of corporate investments, or human life, or the state of the world as we know it - I would tell you to contact me offline and I have a nice team of smart people handy who can take this problem off your hands... for a fee.  The whole area becomes a chicken and egg scenario pretty fast, as every communication and procedure around checking this stuff needs to be handled with care, since any system is only as strong as its weakest link.  What I'm throwing in here assumes that you don't have anything huge, you're mostly working on a newish system that needs just a bit of protection - the equivalent of throwing up a nice gate around your house.  Not a gate, guard dogs, security cameras, and a big guy with a spiked club. :)
Now... key storage
Key storage has two main elements:

How safe does it have to be from attack?
How does it need to be accessed?

"Safe" is often rated in FIPS compliance levels - it's a way of testing key storage mechanisms and that they meet certain sets of escalating security requirements.  The low end is software storage - the key uses one of several commercially supported storage mechanisms and it sits on your hard drive (Price = free or the price of a tiny bit of memory on your hard drive).  The high end is a big, expensive box (an HSM - hardware security module) that will hold your key in such a way that no one can get the key out of the box... ever... and when they try, if they try too hard, the box will zerioze itself, erasing the key.  There's levels in between.
How much safety you want to pay for is entirely a risk/cost decision.  You have to calculate what you have to loose vs. what you want to pay.
"How to access" has a couple of elements:

Software keys are easy to access on the box - there's a couple of commercially supported ways of storing them and most servers support most storage mechanisms.  PKCS12, and JKS are two examples.
Hardware keys are typically accessed by the PKCS 11 protocol (but there are others), most high end servers have this built in, but sometimes you need extensions to handle this or APIs for custom built code.  Also, you have a chicken/egg problem - you usually need a password to get access to your HSM - where and how you store that password is another area of security.
for clients, you also have the mobility problem.  If "client" is a fixed point - you have the same HW/SW options as for servers, but if "client" means a human, then you also need to think about user mobility and compatibility with any GUI mechanism (for example, a browser).  It still boils down to HW/SW, but often the HW element is called a "token", because remove-ability becomes a key feature.

In all cases, you can store your certificates just about anywhere - they are public information that can be distributed far and wide.  The critical element is your private key - which must be stored in a place that only the entity using it can get to.
Who can use a single certificate
It depends on how you are storing your keys and what risk you are willing to accept.  A key on a network accessible HSM could technically be used by a bank of servers, which would let all servers look like one server (pretty cool for a web app).  But if you need to have proof of exactly which client or server did a specific action, then you must have 1 certificate per entity.  Also, you can only revoke a certificate - so you want a level of separation that if you believe a key store had been compromised, you could disable just one thing.
Generally, it's a checkpoint if you find yourself putting the private key in multiple places - that's a serious risk and a good indicator that you want to get another certificate.  From there, the level of separation is, IMO, mostly a matter of what level you want to track and any other needs you have for controlling access.


This looks more complex on the surface than it actually is. What you basically want to do, is secure communication between a web client and a web server over TLS. It doesn't matter which web technology is in use, because TLS happens on the transport layer and not on the application layer.

What happens under the hood? When a client wants to use your application, it requests the JavaScript files from your IIS and executes them in the local browser. Whenever the clients need information from the backend, your NodeJS REST API, it sends a HTTP request the the respective API.

This means, all you need to do, is:

Enable TLS on your API backend
Change all the URLs in the application to HTTPS

This ensures that all requests from the client to the backend are encrypted with TLS. How to set up HTTPS depends on the server you use to run the NodeJS REST API.


Are there vunerabilities with this authentication mechanism?

I am trying to come up with a way to implement token-based authentication for a REST API without the need for SSL.

Don't!

Use SSL (well, TLS actually).

  nothing that isn't public already is going over the wire

This is obviously not exact:

the user name is captured; TLS would hide user name (I am not saying it is a serious still, but it is an information which is disclosed);
a hash based on available information is captured and passwords can now be tried (dictionary attack).

  I have only started looking at security therefore pretty much a novice at this stuff so any help/advice would be appreciated!

Use the proper tools. Don't try make your own protocols. If you try to come up with your own security protocols, they will almost always be flawed.

There are many issues with your protocol:

discloses user name (might not be huge issue, but still)
discloses password hash: allows off-line attack on password
the server needs to know all passwords in clear-text (either by storing them in clear-text, or storing them encrypted with symmetric encryption, and storing the encryption key) (well not the user password, but the real user secret authenticator)
and the worst part: absolutely no protection against an active attacker

Replying to your update:

  I should have been more clear with regards to the SSL.... it's not that I am trying my best to avoid using SSL, it's more catering for the scenario where it isn't an option.

Why isn't it an option in this scenario?

  Also, please target your answers more to the reasons why this approach wouldn't work & if it could be tweaked to work rather than "use SSL".

TLS gives you transport level "security": secrecy and integrity (actually, secrecy is limited, as the size of message is leaked; the secrecy of fixed-size keys is protected).

It can be "tweaked" to work without actually using TLS, if you reimplement most of TLS to get transport security without TLS. The implementation cost would be great, and even if you can get all the details right, your implementation might not perform as well as a carefully optimised TLS implementation.

The important question is why you would not want to use TLS.


What you describe is not forward secrecy.

Forward secrecy relates to the following property: a secured communication took place between entities A and B at some time T; the attacker recorded all the messages; at some later time T' the attacker obtains a copy of all the secret keys known to A and B; and yet, the attacker cannot recover the contents of the communication which occurred at time T. To achieve forward secrecy, then the following must hold:

Each communication (say, each individual message in a mail context) uses a specific encryption key that sender and recipient do not keep around. This necessarily entails some generation mechanism, with randomness.
It does not support stateless one-way emailing. Indeed, if the complete communication between two scouts is a single message from scout A to scout B, then this means that B "knows enough" to process the message and recover the contents. Unless B forces himself to forget what he once knew (i.e. is not stateless), B could do this feat again; and so can the attacker if he obtained all of B's secrets.

If two-way communications are possible (e.g. as with a SSL connection, with the initial handshake), then a key exchange algorithm like Diffie-Hellman can be used to produce a communication-specific session key, used only for the duration of the connection, and discarded afterwards. Any long-term secret known to both scouts will be used only for mutual authentication.

Since scout messages are one-way, and the average scout won't compute a 1024-bit DH key exchange anyway (he could: all these youngsters nowadays have smartphones, which are entirely up to the task; but I understand that is not the pedagogical point), this kind of solution cannot be used.

Instead, the solution is to make the scouts stateful. The model, here, is that of the One-Time Pad: make it so that sender and receiver share a long sequence of secrets, which they store on some physical medium such as a booklet. When they use a key (say a booklet page) for sending or receiving a message, they destroy it. Therefore, an enemy seizing the booklet after the fact will not obtain the key, and thus won't be able to decrypt a past message.

This is the historically correct solution; in the pre-computer era, field agents used OTP. Scouts can only be thrilled by using the exact same method as real spies and armies used for decades. Extra points for making the booklet in an edible material, so that destruction after usage is fun, easy and safe (the average scout would also find it quite fun to simply burn down the paper, but that might create environmental hazards). Further extra points for walking the scouts through cryptanalysis when OTP was badly used, i.e. the pad has been reused.

Forward secrecy is about what happens when a field agent is seized by the enemy, and forced to reveal his secrets. The scenario you envision is different: no secret forcibly revealed, but a passive decryption which occurred in an unspecified way (e.g. a lot of guesswork from a partially known plaintext). The property you describe (decrypting one message does not reveal other messages) only means that the encryption method is robust against known-plaintext attacks: even knowing some cleartext and the corresponding ciphertext is not enough to enable decryption of other ciphertext, and, in particular, is not enough to rebuild any keying component which is reused for other messages.

Pen-and-paper ciphers are usually weak, although some can be quite strong when the attacker only has a pen and paper too. See this question for suggestion and links.

One-Time Pad is the exception: it is computable with very low computing power, and yet is ultimately robust against known-plaintext attacks, because no employed keying component is reused for another message or message part.

Summary: use OTP. It provides the property you want; it also provides forward secrecy. It is pedagogical, and amenable to enlightening historical reconstruction.


Extending on-premise security to a virtual machine used in Home Office environment

There are considerable differences once you begin to look at support, help desk, patching, upgrades, lost hardware, incompatibilities with security settings or applications on the personal hardware etc...

I'd suggest if they don't offer this the best you can do is ask if they will consider it. They may implement a solution that works for you, if it makes sense for them to do so.


In Windows, there can be a problem with kernel adresses. Each service pack has different kernel addresses. I'd suggest taking "cross platform" shellcode from exploit-db.com or packetstormsecurity.org


why is it necessary to have both code signing and time stamping certificates?

As a software publisher, you typically just buy one certificate, not two.  You buy a code signing certificate, use it to make a signature, and then get that signature timestamped to prove that you made the signature before your code signing certificate expired.  The timestamping is done by a server run by a certificate authority, and they sign the timestamp using their own certificate; you don't need to provide one at that point.

I don't think anything special happens when certificates in the chain of trust of your timestamp expire, but I could be wrong.


Anyone use the International Domain Name (IDN) security mitigation API's? Is there a wrapper for .NET?

1) Microsoft's API's are limited in scope of protection.  And no a .NET wrapper does not exist.  The IDN mitigation API's are limited to conversions between IDN and ASCII (punycode) and providing some rudimentary checking of mixed script as a security precaution.

2) Something like http://www.casaba.com/products/UCAPI/ will provide more significant detection of string confusability including the presence of confusable characters in IDN. This API also allows for comparison of two strings such as:

IsStringConfusable(source, DetectionMethods)
AreStringsConfusable(source, target, DetectionMethods)

UCAPI does have a .NET API but it's neither public nor open source.

3) An open source alternative would be ICU at http://www.icu-project.org/ which includes an API also for detecting confusables similar to UCAPI above.  However ICU is C, C++, and Java only.


Best practice for multi-factor re-authentication

As best as I can tell, there is no standard or best practice for this. Based on the comments and a discussion with management, we set the re-authorization interval to 16 hours, meaning that it will prompt the users once per work day.


Has anyone heard of cases where SSL Certificate insurance/warranty paid out?

The problem with your question is that such a pay out would require that there be a fundamental flaw in the implementation and that the paid warranty would not be under a strict NDA. If it has paid out, no one would know. And, it is unlikely to ever need paying out (given the nature of TLS certificates).

But I'm concerned about your either/or about this being a "scam". It's an easy "bonus" for the vendor to add because the risk is low of ever needing to pay out. That does not mean that it is a scam. If someone could prove harm, and the vendor did not pay out, then there would be press about that fact. I could offer you protection, free of charge, against dragon attacks, and that does not make it a scam.


In the case of the Gawker data breach, would strong passwords be ok?

The strength of a password is related to two things:

Entropy -- Relative strength as measured in bits.
Iteration speed -- How long it would take to exhaustively test against a certain function.

Gawker used DES crypt hash method (not the best choice). That seems to be roughly 10 times slower to brute force than MD5. A GeForce 8800 Ultra (2007 vintage) is widely cited as tackling 200 million MD5 hashes per second. My GeForce 560 TI is about four times as fast. 200*4/10 = 80 million DES crypt hashes per second.

A password of 26+26+10+10 (lower, upper, numbers, 10 symbols) and 12 characters long is worth 274 bits of entropy. DES maxes out at 256.  Wolfram Alpha tells me you've got a little bit of wiggle room against one graphics card at 256 bits of entropy.

Alternately, there's the DES cracker perspective where the entire keyspace could be tested in about 10 days in 1998 by an EFF pet project. Thus, your relatively strong password might still be defeated by the limitations of a smaller hashing space and a quickly attacked algorithm.

I wouldn't hold my breath, but at least you won't end up on a top passwords list.


What are web attacks which users can run code on your servers?

To be able to run code on your server, I could:

Upload a file using one of your web forms. But instead of an image, I upload a PHP file. Then I can run the code in the PHP file with the privileges of the webserver process.
Exploit a buffer overflow to get a shell on your server.
Log in as an administrator and upload code:

Social engineer the password from one of your administrators.
Use an XSS attack to steal session cookies from one of your administrators.
Use an SQL injection attack to read the password table, then:

read the passwords that you stored in cleartext, or
run a password guessing program to crack your poorly chosen passwords.

Use a directory traversal attack to get a copy of your system password file and use one of the password-cracking methods mentioned above.
Physically steal a backup tape to get a copy of your database and use one of the password-cracking methods mentioned above.

Use any of dozens of methods of taking over a machine on your intranet and using that as a platform to upload code to the web server.
Physically get myself in front of your server console.

Note that I don't necessarily have to attack your app. I can attack vulnerabilities in your webserver, OS, or people for example.


A git repository is just files. So you're asking "Are private files safe?" To which the answer is "you're asking the wrong question".

A git repository is exactly as safe as the place that it storing it for you. No more, no less. If it's GitHub, then it's exactly as safe as GitHub is, And before you ask how safe GitHub is: nobody knows the answer but them.

Same story for BitBucket, Gitorius, Dropbox, Google Apps, Microsoft OneDrive and literally everywhere else you can store files (including your Git repo): Nobody can tell you how safe they are because nobody knows but the vendor. And the vendor always says they're safe.

If you're paranoid, keep your files on your own hard drive. In a mattress. Buried behind the shed.


The NSA circumvents encryption and how would I protect myself from these type of attacks?

Once a well-funded and knowledgeable attacker has exploited a 0-day to install arbitrary code on your computer, it is game over. There's no way to defend against that. The only defenses are to make sure that such an attack is not possible (very difficult) or ensure that no harm comes from such an attack (ie: that computer never handles sensitive data).

This leads to the awkward strategy of having an air-gapped computer that you use for encryption and decryption and another computer that you use for communication. You would use PGP on the air-gapped computer to encrypt/decrypt and move your data to/from the networked computer for transmission. Sending data in this manner is relatively simple. Just put the encrypted data on a DVD and move it to the networked computer.

Moving received data from the network computer to the air-gapped computer would have to be done in a way that would ensure that the air-gapped computer can't be hacked. This means that you probably should't use something like a USB or DVD as you can't trust them to be secure as the networked computer may have been hacked and use the USB/DVD to infect the air-gapped computer. Perhaps printing out the data from the networked computer and then using OCR to import it to the air-gapped computer?

The above notwithstanding, I think the best solution is to make yourself uninteresting to the NSA.


How can two parties compare whether a simple (5 letter) shared word matches, without disclosing their word to each other?

The problem you are asking about is called the Socialist Millionaire problem and has been discussed in research before; as far as I know there is a protocol to do this comparison without disclosing any of the two secrets and without involvement of a third party. I will edit my answer with a full explanation as soon as possible.