How does encryption/decryption work when one generate random key?

PBKDF2, as the name suggests, is a key derivation function. It means that the algorithm takes some parameters (including a password since it is a password based key derivation function) and produce a key of arbitrary length. Even if PBKDF2 is expecting some random values as parameters (for instance, the salt), when you pass the same parameters to the function, it always returns the same key.

It means also that when you are using PBKDF2 to encrypts a file you also have to store all parameters (i.e. for PBKDF2: the Pseudo-random function, the salt, the number of iterations, the length of generated key) along with the encrypted file. Indeed, these parameters will be necessary to recompute the same key from the same password when decrypting the file.


How do I track IPs my computer is accessing?

To track outbound connections from your system, likely the best approach would be to use software like Little Snitch for Mac OSX or Glasswire for Windows which can log these connections and also alert/block as needed.


No, you don't increase the security. As you point out, both peers have to know both PSKs.

  Are both PSKs are used to set up a connection and both must be right? Or is only the initiator's OR responder's PSK used?

Each peer would use its "local" PSK to produce the AUTH payload in the IKE_AUTH message it sends.

And each peer would use the "remote" PSK to verify that the received AUTH payload was produced with knowledge of the corresponding PSK (which in turn requires that same PSK).


Facebook password lowercase and uppercase

This is simply Facebook trying to provide a better user experience for those users who may have Caps Lock enabled, or whose devices automatically capitalize the first letter of the password.

I don't think there are any cookies per your question. It is likely that the password hashing and storage is as standard as you would expect. The alternate passwords are probably generated from the password submitted, via the login form, and not stored as alternates on the back end.

It appears that they are only flipping a-zA-Z, and not a mix of incorrect case. They are also checking against a capitalzied first character as pointed out by PwdRsch in the comments.

While this may increase the online brute force attack surface, if you use a password of high entropy, it's pretty unlikely that this would prove to be much of a security risk in my opinion.

i.e:

Password: aBcDeF123
Works:    AbCdEf123  // Flipped Case
Works:    ABcDeF123  // Caps First Char
Doesnt:   ABCDEF123  // Mixed Case
Doesnt:   AbCdEf!@#  // Shifted Numbers


Is it possible to build completely verifiable hardware?

Not really, or at least it is very hard.

Recently a research paper on Stealthy Dopant-Level Hardware Trojans was published which shows how to include a Trojan into hardware that is so hard to detect that even if we optically compared the chip to a non-tampered unit we wouldn't find it. Read the abstract of the paper for an overview and if you want to know more about the methods of verification that are used and can be circumvented then read of the whole thing.

If there was an open source chip that is being produced by companies A and B that had the same blueprints and then one of the companies decided to include a dopant-level trojan, then a user has almost no possibility of detecting the trojan. The tools for testing are expensive (like electron microscopes ie. really expensive) and still might fail. Hardware trojans get triggered by very rare circumstances they are almost impossible to find using functional testing.

This level of hardware trojans have not been seen in the wild yet. It might be that they don't exist, but it might also be that they have not been detected or their disclosure has not been public.


nmap scanning - What is the difference between -sP and -sn?

There is no difference.  To quote man nmap:

In previous releases of Nmap, -sn was known as -sP.


As @D.W. points out, this would work -- to protect the cookie. The path itself comes before the headers, and may also be at risk, if it contains sensitive data at a predictable place (this is not a common case nowadays, but URL rewriting for session management used to be popular).

A variant would look like this:

GET / HTTP/1.1
X-Header-Padding1: <X random padding bytes>
Accept: */*
Cookie: ...
...
X-Header-Padding2: <Y random padding bytes>

By choosing X and Y randomly, but such that X+Y is fixed, the emplacement of the cookie in the stream would change between requests, in a way which attackers cannot detect (since the total length of the headers is constant). While not as satisfying as simply dropping the first 256 bytes of the request, this ought to be enough to bring back the effort of bias-based attacks into the billions of requests, instead of millions, and it could be done with less than 256 extra bytes per request (having X+Y = 32 should do that).


Advantages of TLS-SRP when the secret must be exchanged online?

SRP is for situations where you already have a shared secret between client and server, e.g. as part of a "pairing" procedure which would occur naturally in your context (for instance, SRP has been proposed for Bluetooth peripherals: one device has a screen and displays a code, the other device has a keypad on which the code is entered). For a "fully online" situation where there never is any occasion to obtain such a shared secret, SRP has little advantage. Security has to start somewhere.

In SRP, what the server stores is indeed a sort-of hash of the password -- only "sort-of" because the stored value must also fulfil some mathematical structure so that it can be used in the protocol. That value cannot be immediately used to authenticate as a client, but, like any hashed password, it is indeed susceptible to brute force. The magic of SRP is that observing data packets on the wire is not sufficient to apply a dictionary attack on the password; however, what the server stores allows such an attack (and, in a very general way, this is unavoidable).

In TLS/SRP as currently specified, the value stored on the server is computed as:

    x = SHA1(s | SHA1(I | ":" | P))
    v = g^x % N

where s is the salt, I the user name, P the password, and v is that which is stored (x is not stored). g and N are SRP parameters (public). If the attacker can obtain the value v, then he can "try passwords" by doing the computation above.

This is a salted hash (that's good), but it is also a quite fast hash (that's bad). SRP could be coupled with a good password hashing function (e.g. bcrypt), with the following caveats:

There is no specified or de facto standard for that. But both client and server must agree on the particular.
If slow hashing is used, then, when a connection is performed, it must occur on the client, not on the server. So this will run at the speed of the client.


1 - What you are doing is valid, you are doing good.

2 - You shouldn't use the key on step 1 to sign, but key from step 2. The key from step 1 is for the CA, and you should only use it for signing other certificates. You could create a dedicated certificate for signing firmware, or use the API endpoint certificate to sign them. It works the same.

The key from step 1 is the most sensitive part of your infrastructure. Treat is as the master-key. Use it only for signing other certificates.


Should we encrypt data in a multi-tenancy product in the cloud?

In the shared environment like the cloud, there is always the possibility of data leakage. Therefore encrypting data is a great way to prevent anyone from seeing the data they are not authorized to see. Encryption involves the use of keys and without the access to the proper keys, the data is unreadable and unusable. So the data for each tenant should be encrypted using their own keys.


Protecting private encrypted data on public computers

First of all, let me say that your scenario is quite bad. Storing copies of personal information on an unsecured laptop that people could rob rings a number of bells, and my first instinct would be to ask why do you really need to do that?? It may be possible to handle it on a better way. And even if budget restrictions are a concern, do note that they need to be compared with the risk associated to improperly leaking that data (both monetary -someone sues you for 'losing' that data- and reputationally for the company).

Now, assuming that those restrictions hold, what you are describing doesn't sound too bad. Obviously, the QR code holding the password could be easily stolen by anyone with a smartphone, and the application, associated database and login password could be copied to a usb drive in minutes by an attacker that knew what to steal (hint: disable usb ports). Also, the AES key is most probably still stored in some memory allocated to the Java VM process.

The main suggestion I would make to your approach is to automatically lock/shutdown the laptop when it is taken outside the allowed area.

One way to do that would be if it carried a GPS received (common in smartphones, not so much on laptops).
Usually a check on available WiFi networks would serve well. You state that the laptop is not connected to any network, but perhaps there is a near network that it can take as a signal of being 'on the right location', even if it doesn't connect to it?
However, a more basic detection would be to rely on the power cord being connected. I assume that the laptop will have to be connected to the power in that public location. You could detect the event noting that it is running on battery as a signal to lock the application.
And the most simple way to force the laptop to lock if removed from the location would be to deploy it with no battery at all. Physical theft of the laptop would require disconnecting it from the power cord, which would automatically shutdown the laptop, locking the database.


hashcat - is there a way to set minimum password length?

Sounds like you're looking for --increment-min. This will start a bruteforce/mask attack at a minimum length.

For example, this will try digits-only candidates, starting with length 7:

hashcat -a 3 -m [hashtype] -i --increment-min=7 targethashes.list ?d?d?d?d?d?d?d?d?d?d

You didn't directly ask this, but the deeper intent of your question appears to be "what can I do beyond a dictionary attack?"

There are many other options to try before you go full bruteforce - combinator, hybrid, masks. See hashcat's core attack modes for some introductory materials.


Why are apps for mobile devices more restrictive than for desktop?

I think the comment of @Luc is as giving a direction that merits to be expanded here into an answer.

Consider the following. The hardware to have a 0.5lb mobile device run at 480p resolution etc is quite recent. Consequently it is only recently that those mobile systems you mention in your question exists. Desktop system which have been able to use big/heavy hardware (not mobile) has been around for much longer. The X Windows System for instance being an basis for many so Desktop system has been around since aprox. 1984 a time at which Internet and Networking and Applications have looked quite differently. Without the "high-speed broad-band everything connected" the exposition for attacks and hence the necessity for sandboxing has been different. The novelty of the mobile systems allowed to disregard largerly backwards compatibility issues and facilitated to implement techniques to address today`s risk/security threat situation.

Sticking to the example of X Server (i.e XOrg/XFree86) the need to protect applications from each other was not initially seen as it was rare that you installed untrusted code from less known origins. The number of apps making use of libXOrg or derivates was much smaller and changes was that one could have trusted all Applications that one allows to run on your system. With more and more applications from evermore diverse unknown origins makes this trust model difficult. Unluckily for being able to stick with compatibility (in case of the example of the X Server) the model is still used today. Therefore it is even today possible for one application to keylog the input of other applications in the same XSession, something that maybe not have been considered a threat/risk back then, as few X Applications were known and trusted to be bigger extend. Just as @Luc suggests the catching up is occuring and we see for example that some replacements for X Server, like the famous Wayland is considering models that move into including sandboxing and separation and in general a more modern day trust model.

The historical reasons sketched above (i.e. different threat situation at the time of the creation of mobile vs desktop system) is of course enhanced with potential other reasons and surely not a monocausal thing. The notion that sandboxing techniques will enhance the situation of power the owner/creator of the OS/system relatively to the app creators potential coercing them to comply with the agenda of the former.


Are there any risks involved with plugging smartphones into Windows 7-10 computer's USB ports?

For automatic driver installation specifically:
Windows installs drivers automatically if they are in-box (that is, included with the OS), or if they are on Windows Update and you have the optional (but I think enabled-by-default) feature to search Windows Update for needed drivers. In both cases, these drivers will be "blessed" by Microsoft with a WHQL (Windows Hardware Qualification Labs) signature - this is necessary to install a driver in 64-bit Windows at all, unless you mess with the boot parameters - meaning that they have been tested for some level of correctness and also come from a known, verified vendor.
Note that WHQL signatures, and even in-box or WU distribution, do not guarantee that the driver has no security vulnerabilities. Driver security is a complicated topic that lots of hardware vendors make mistakes on - there was a high-profile case recently where NVIDIA's graphics driver was found to have some serious vulnerabilities and they pushed an urgent patch - and of course drivers have such a privileged position that vulnerabilities in them can compromise the entire system. On the other hand, if a driver isn't loaded, it doesn't matter how vulnerable it is, and loading a driver requires Admin privileges so low-privilege malware can't just load a known-vulnerable driver to gain an EoP vector.
WHQL also doesn't guarantee the stability of the driver, beyond for basic steps like loading and unloading. Driver instability has long been a leading cause of kernel panics (Blue Screens of Death), though it's unlikely for any WHQL driver to cause a BSOD just from plugging in its hardware.
Also, depending on the phone and how it's configured, the phone itself might not need its own driver. A phone that is connected in USB Mass Storage (UMS) or Media Transfer Protocol (MTP) modes will use a generic Windows driver that supports such modes. These drivers are written by Microsoft and subjected to extensive testing (though of course there can still be bugs).
Do note that, for "active" multi-function devices like smartphones, there may be many different drivers, as the device can present itself as any kind of USB device or even as a hub (which has its own generic driver) with many different devices connected to it.

Outside of drivers specifically, smartphones could also be used for other attacks. There are many kinds of malicious USB devices out there, such as "Rubber Duckies" that type attacker-chosen keystrokes at superhuman speed, or even a "USB Killer" that uses a large power surge to destroy the USB port and possibly other components. Plugging in unknown, untrusted USB devices is risky behavior, and that includes phones!


This is no different from other aspects of network and system configuration. PCI is mostly concerned with separation of duties, so the sysadmin is not also the dba and is not also the developer, and with auditability, so that changes are recorded and approved and implementation matches policy. So sites can run internal NTP servers. Demonstrate that there is a formal policy for their use, that they are under sufficient custody to be accurate and reliable, that changes to their config go through change management, and that the hosts in PCI space cant be made not to use the approved internal source.


In what ways can you trust a third party server with your data?

This depends completely on your situation.
As a private person, there is little you can do. You can read-up on the provider. Is this a trustworthy party? Or is it a party that easily sells its data? Read the fine print of the EULA. If the provider has a history of data leaks, they should be in the news. Is the provider is in a jurisdiction that forces the handover of all data and has a gagging-order history? You might want to avoid that, unless you trust that government.
ISO norms may give you some more reason to trust a provider.
As a company, you may look at your contracts. A smaller provider will generally be more willing to accommodate you. As a company, we normally have a right to audit (which we actually do too), which gives us more trust. There is also the possibility of independent audits.


Account-lock security policy (username/password)

There is no right or wrong answer. The more aggressive lockout policy is slightly more secure, and slightly less convenient for your users. You have to assess if it is worth doing based on your application's requirements, your knowledge of your user base, the value of the asset you are protecting, your threat model, etc. etc.


How to use a different key and IV for encrypting a file with AES in C++?

Using the same Key and IV pair for multiple file encryption is very dangerous because encrypting the two files with the same same content will result the same ciphertext for any block mode encryption. Here are a few related posts about this:

Why must IV/key-pairs not be reused in CTR mode?

Dangers of using CTR mode for encryption

AES-CBC and IV — Encrypting multiple blocks of a file with the same IV?

  It is insecure to reuse the IV with AES-CBC. At the very least, if the
  files have a common prefix, this will be revealed as a common prefix
  of the ciphertexts. For AES-CBC, the only way to ensure
  confidentiality is to use random IVs.

What are the constraints for an IV using AES in CBC mode?

  The IV for a block cipher in CBC mode must not only be "uniquely used
  for each message encrypted with the same key". It is usually assumed
  to be indistinguishable from random by an adversary.

Note that using the same key and iv pair for GCM mode would result disastrous consequences in any case. You can check the following question (in fact, in most of questions related to GCM mode, you would see people mentioning this case of wrong usage. )

How bad it is using the same IV twice with AES/GCM?

My advice is to use random symmetric key and random IV for each file encryption and store these in the encrypted file using Cryptographic Message Syntax(CMS), you can use EnvelopedData content type in which you store encrypted content. In this case, the content encryption key(CEK)(random symmetric key) is encrypted using the user's public key (could be reached from user's certificate) and stored as encrypted with the encrypted content. As for the random IV, it is stored as open because it does not need to be private it only needs to be unpredictable. When a user needs to decrypt a file, s/he basicly decrypts CEK using the private key that s/he has. From there, using CEK and the IV one can decrypt the encrypted content.

If you cannot or would not want to use CMS, you can use the same key with different IVs for multiple files encryption. I dont know any weakness for this use. You should store your key as encrypted but you can store the IVs as unencrypted. Note, you may want to store them as signed to see if they are changed or not without your notice.


... does it means that in that specific date, that IP hosted that domain name?

It just means that a DNS lookup for the domain returned the given address.

It does not mean that there was some HTTP server at this host which was configured to respond to this domain name or that other services at the IP address where aware that they were reached through this domain name.

  ... it could not be that mentioned IP resolved to that domain name in a date before "2019-04-20"

First, this is not about an IP address resolving to a domain name but a domain name resolving to an IP address. There can actually be multiple domain names resolving to a single IP address but also one domain name resolving to multiple IP addresses. Resolving from IP to a domain name would be DNS PTR records - but this is not what this feature is about.

Also, passive DNS replication is based on watching DNS traffic. To cite from the blog article at VirusTotal: "... technology which constructs zone replicas without cooperation from zone administrators, based on captured name server responses ...". This means that they can only replicate DNS configuration for domains which were actively queried and where the queries were seen by the DNS servers or traffic nodes they control. Thus it can still be that the domain had this IP address before, only that no access to the domain was seen before and thus no previous configuration could be determined.


Alternative ways to manage lots of Passwords since Lastpass was hacked & now acquired

This really depends on your threat model.  Depending on what information you're protecting (and who you're protecting it against), Lastpass is just fine.  With a different model, you can use KeePass on a standalone, airgapped, encrypted Unix machine and pray to God your info is safe.

Lastpass is fine for your recipe web site account.  To some extent, they're excellent for even other personal consumer account protection.  Remember, Lastpass uses "zero-knowledge" encryption, so by design, the fact that they host your password data is no different from one of the alternatives you mentioned....

Which is KeePass + your cloud service account. I really have no idea what advantage you gain by doing this instead of just using Lastpass anyway.  Seriously, what's the difference?

KeePass stored on your local machine will be about as secure as your machine (or any local media the password database is stored) is.

The best way to approach the problem is to do your own personal risk management analysis. That just means... figure out what's most critical to protect.  Figure out whats less important, and finally what's least important. Consider what/who you're protecting that data against, and then plan your defense strategy accordingly.

It really should (and does) depend on all these factors combined. There is no one perfect answer.


What questions should I ask a vendor that provides hosted encrypted email?

This sounds like a closed communication system where the content isn't actually "sent" from their system.  You mention that data is encrypted once entered and that:

  "All encryption keys (one-way) are stored on the service provider's
  systems and are secured with the users' password."

I'm not certain what you mean by "one-way" here, but I'll assume you're referring to symmetric encryption which uses a single key such as AES.  My questions here would be what encryption algorithm they're using, and how are the keys generated and stored.  Are they using password-based key derivation?  If so, are the generated keys stored anywhere?  If not, how are they storing the keys they're generating?  As for the account itself, what processes are in place to reset a lost password and how difficult would it be to impersonate a user on their system?

As for a scenario, if a FBI were to walk into the data center and roll out a rack of servers and theirs happened to be among those taken (whatever the reason), would they be able to access the stored data with physical access to the equipment?  What procedures are in place to protect data in the event of a physical security breach?

Also, how are they backing up their data?  On-site?  Off-site?  Is the backup encrypted and who has access to it?


Why does this XSS challenge require %0A to work?

It's required to terminate a Javascript comment.

The challenge enforces a link format along the lines of [a-z]*://.*. Here, the idea is to inject JS via the javascript: pseudo protocol. So, in order to adhere to the link format, you have to start your sequence with javascript://.

But since everything behind the colon is interpreted as JS, you run into a problem: // introduces a single-line comment in JS, so everything that comes after it will be commented out until a newline character appears. This will do nothing:

//alert(1)

%0a is the URL-encoded version of an ASCII newline, so your payload effectively becomes this:

//
alert(1)


It's doing exactly as it's designed to do. The Facebook Cert is designed to allow trusted connections only to domain names for Facebook. Your personal Cert is designed only to work for that personal domain. Just because you have a valid Cert doesn't allow you to spoof any domain you wish.


Is there any alternative to nmap for UDP?

First of all you can use the -T5 parameter on nmap, which is the fastest rate possible. By default, nmap uses -T4. Still you won't get as quick results as you would with masscan.
According to the creator's github:
This is an Internet-scale port scanner. It can scan the entire Internet in under 6 minutes, transmitting 10 million packets per second, from a single machine.

It's input/output is similar to nmap, the most famous port scanner. When in doubt, try one of those features.

Internally, it uses asynchronous tranmissions, similar to port scanners like scanrand, unicornscan, and ZMap. It's more flexible, allowing arbitrary port and address ranges.

In practice many penetration testers, including myself, use it to quickly scan devices for open ports and then take the results to nmap for more information.
For example, the command below will scan a host on all TCP (-p1-65535) and UDP (-pU:1-65535). In just a few minutes you will have all open ports and you can use nmap to scan ONLY them for services etc.
masscan -p1-65535,U:1-65535 10.10.10.x --rate=1000


known public exploits for vsftpd 2.0.1/2.0.5

Exploit-db finds 3 exploits (click link). 1 for that specific version and 2 for higher versions.

OSVDB shows 11 exploits however you have to click each ID to see which version the exploits are for.

cve.mitre.org also reports 11 exploits. Versions are listed in the description. There are some there specific for 2.0.5.


What has to occur for a hacker to monitor traffic from my LAN?

If the hacker knows the SSID of my access point and the password (WPA2), could he sniff the traffic of my local network?

If they have access to both your SSID and have your WPA2 password, then they will be able to monitor any traffic going between you and the router. This is of course limited to unencrypted connections. If you use websites that have HTTPS, then while the attacker will obtain the raw data you are transmitting, they will not be able to decrypt it. HTTPS adds another layer to the encryption.

Note that an active attacker could also tamper with traffic, for example by injecting malware into websites or redirecting logins to a phishing site. This is a reason why a secure password is important.

  Is it necessary to capture the authentication handshake between the device and the access point in order to decrypt the IEEE 802.11 traffic? If so, how this process could be done?

It used to be, but a new method has been discovered which allows the attacker to bypass that stage. However, simply obtaining the handshake (or using the new technique) does not automatically give them access. They will still need to crack your password, and if your password is strong, you will be safe from that. Make sure your password is difficult to guess. Remember that computers can guess at hundreds of millions of times per second, so take that into account when creating a strong password.

  If the hacker now the SSID of my access point but not the password, could he still be able to sniff the traffic of my local network?

Sort of. He would be able to monitor and record the traffic but not decrypt it. If he later obtained the password (e.g. by cracking it or by stealing it from you), he would be able to retroactively decrypt everything he has recorded so far. This means that you need to make sure your password is secure and stays secure to prevent retroactive decryption at any point in the future.


How do I securely exchange server logins with remote developers?

Ask for their SSH public keys, and add those to the authorized_keys lists for the hosts they'll be logging in to. It's safe to disclose public keys so they can be distributed over non-confidential media such as email.


Why CA are mandatory to trust our public key? What if we publish the public key via DNS like in DKIM?

DNS itself is not secure.  DNS allows for relaying, so any DNS server that is in the path that a client uses to resolve the domain could lie, or the DNS request itself could be attacked via a MITM.  DNSSEC attempts to correct some of this by signing DNS records so that only the owner of a domain can post DNS records authoritatively, but that only works if a) the DNS servers use DNSSEC and b) the attacker isn't able to attack in such a way that the domain is processed as if it didn't have DNSSEC.

Additionally, even if DNS was secure, third party SSL signing serves a different purpose for trust.  A CA's signature on a certificate means that someone other than the person issuing the cert has verified the details.  If I go to mybankphishingsite.com I don't know if they are actually my bank or not.  If they just post a certificate on their DNS (which they rightly control as they registered the domain) then they could say they are My Bank Corp.  With a CA signing the cert however, the details have to be verified.

When they ask for a cert that says they are My Bank Corp, they have to provide documentation that they actually are My Bank Corp, so mybankphishingsite.com can't get a cert that says they are My Bank Corp, but myactualbank.com can get one.  This lets me, as a user, know that I can trust myactualbank.com because a trusted third party has verified who they are.


What kinds of attacks would be missed if we don't look at both host and network activity

I'll turn your question around:

  "What attacks can only be detected by a combination of host and
  network data?"

And the answer to that question is: not many.

The true power of correlation of host and network data is the ability to see 'beyond' the attack to see how widespread it is and where it originated from. In other words, you correlate those two data sets in order to help you respond, not just identify.

An anti-malware detection algorithm can identify an attack on a host, but the other sources of data can provide what you need to eradicate it, not just from the host, but from your entire environment.

The wider view might be considered the 'real' attack, if that's what you meant. And, if you didn't mean that, it should be included in your consideration.


how should I protect url parameter in JPQL query for reset password flow

I'm not quite sure what you are referring to when you say you are using "Hibernate" (NHibernate?)

Either way - usually when you see the pattern of replacing a parameter with a ? it suggests that you are working with a parameterized query.  If it is using parameterized queries then you will be protected from SQL Injection in your situation.

If you can clarify which technology you are using I can give a clearer answer.


Should admin make SMTP to do sanity checks?

While there is absolutely no semblance of security built-in to SMTP, open relays are a known, and solved problem.
To prevent relaying, you simply set up a list on the server of valid destination domains (typically only domains for which local delivery is an option). Then unless the sender is authenticated or otherwise allowed to relay mail, then the server should reject any RCPT TO address that is not one of the allowed domains.
Again, this is a solved problem, and 100% of all popular SMTP server packages support this feature by default.
Failure to properly restrict relaying on your server will quickly get you picked up by spammers as a relay for their junk mail and then immediately blacklisted from delivering legitimate email to all major mail destinations.
NOTE THAT YOUR ISP'S MAIL SERVER IS NOT AN OPEN RELAY
You're explicitly allowed to relay mail through your ISP. In fact, if you are a residential customer, your ISP's mail server should be the only mail server to which you can connect directly on port 25. This is intentional. Your ISP knows who you, they know your personal identity which they can derive from just your IP address.
So when you send email through their server, that email is directly tied not just to your online identity, but to your "real" identity, with the name and address that they know belongs to you. At any point in the future, that email can be traced back to you.
They allow you to relay mail because they are watching what you do. And if you misuse their mail server, you can be held accountable.


SHA-512 unix passwords. How secure are those hashes, really?

The figures you quote are about the number of tried passwords per second. Since this password hashing function is salted, attackers cannot attack more than one hashed password at a time; similarly, they won't be able to build and reuse precomputed tables ("rainbow tables"). Moreover, the function is configurable with a number of iterations ("rounds") so that you can adjust it to a trade-off between the amount of CPU you are willing to spend on each password verification, and the amount of CPU you want the attacker to spend on each cracking attempt. If you double the number of rounds, you make the job twice harder for everybody, you included.

The default number of rounds (5000) was meant to be bearable on average computers of that time; recent PC are faster and increasing that number of rounds for your machine would be a good idea.

Nevertheless, attackers can use special purpose hardware, in particular GPU, to get a boost. The boost depends on how the function is internally computed. SHA-512 consists in a lot of 64-bit arithmetic operations, and GPU are not utterly comfortable with that, so the boost obtained with a GPU (compared with generic CPU, under the same budget) is not as high as it would be with SHA-256 (which uses only 32-bit operations). However, it is expected that a GPU will be a few dozen times faster than a CPU at trying to crack passwords. Exact figures depend a lot on the CPU and the GPU used, but yeah, a 100x speedup is conceivable (I suspect you underestimate your CPU, though: it is multicore, and, furthermore, it has some inherent parallel computation abilities with SSE2 or AVX registers).

Other functions rely on more memory-access operations which make the task harder for a GPU, e.g. bcrypt and scrypt. See this answer for a lot of information on password hashing, and that one for a specific treatment of bcrypt vs PBKDF2 (for the purpose of the discussion here, PBKDF2 is quite comparable to the Unix crypt() function we are talking about).

Anyway, the correct defence is not to have a weak password. If your password is #11500 in the attacker's list, then it is very weak. A reasonable password has at least 30 bits of entropy, so on average the attacker will have to try 500 millions of them before cracking it. At 11500 per second, you have a few hours before you. With a little more memory effort, you can get more than 40 bits of entropy, and transform this "a few hours" into "several years".

See this question for discussions on password entropy. Also, remember that password hashing is a second line of defence which enters into action only when a partial breach has already occurred: in a Unix context, /etc/shadow is not supposed to be readable by non-root users, let alone external clients. So don't get too much worried about password hashing, and concentrate on not allowing SQL injection or buffer overflows.


SSL: Do certificate authorities know anything about a website's users?

During the certificate validation the client might contact the CA controlled OCSP responder to check for certificate revocation. Thus, while the CA does not know what exactly the client visits (i.e. does not see traffic and could not decrypt it if it sees it) it might get at least an association between the clients IP address and the certificate of the visited site.

The way around this is OCSP stapling where the server already provides the (CA signed) OCSP response and the client does not  have to access the CA. This is also recommended for performance since the client does not need to create an additional connection for OCSP lookup and wait for the result.


Root SSL certificates and browser support

Nominally, in pure "X.509" philosophy, the SSL client should obtain the server's certificate and all needed intermediate CA certificates in any way it sees fit, but in particular by talking to the Directory, which is the giant worldwide LDAP server which contains everything.

Unfortunately, the Directory never existed (too centralized, too complex) so practical protocols have to include some provision for sending certificates themselves. It so happens in SSL/TLS: the server sends its own certificate and a bunch of other certificates which "may help" the client. In fact, the TLS standard even specifies that the server MUST send a ready-to-validate chain:

certificate_list
  This is a sequence (chain) of certificates.  The sender's
  certificate MUST come first in the list.  Each following
  certificate MUST directly certify the one preceding it.  Because
  certificate validation requires that root keys be distributed
  independently, the self-signed certificate that specifies the root
  certificate authority MAY be omitted from the chain, under the
  assumption that the remote end must already possess it in order to
  validate it in any case.

In particular, notice that the self-signed root itself may or may not be included. This root is never needed client side (and never has been) but sending it is "traditional" (one of the myriads of traditions in IT; not useful, but mostly harmless).

The client should be able to validate the certificate chain "as is" and is allowed (as in "morally justified"), per the TLS standard, to reject the handshake if the exact chain sent by the server cannot be validated. However, the client is also allowed (and encouraged) to try to rebuild some other chain and validate that, if what the server sent was not directly usable. Modern browsers do that; they will try to use locally known intermediate CA certificates (obtained at installation, or cached), and may also download extra CA certificates, following URL found in the certificates themselves (Authority Information Access extension). At least IE on (recent) Windows will do that, but, to avoid a nasty chicken-and-egg situation, it will follow only http:// URL, not https://. These extra downloads can take some time and make the handshake less robust, in case of flaky network or timeout.

Summary: sending the root is not mandatory, but traditional (the +1 kB network overhead per full handshake is unlikely to have any significant or even detectable impact on performance). Sending the intermediate CA is nominally required, and, in practice, recommended, although modern browsers/OS may recover by using alternate certificate chain building strategies.


Are fingerprint scanners easy to bypass?

Fingerprints can be viewed as a fuzzy source of data. Given the same finger, a reader might never read exactly the same print. That is why most readers require the user to scan a finger multiple times during the registration phase.

During the authentication phase, the system tries to determine if the scan it just acquired is "close enough" to the trained data to allow access. This leads to two problems.

Remote authentication
Keeping biometric private

Remote Authentication

Assume I keep my biometric private (we'll deal with that problem later). Can I give another party enough information to correctly authenticate me without requiring them to store enough information to impersonate me (i.e., if someone steals the database, I don't want them to be able to impersonate me)?

It turns out you can. The functions needed are called secure sketches and fuzzy extractors. A secure sketch (SS) is given some data (w) and returns string (s) in other words SS(w)=s. A secure sketch also has a recovery function (Rec). Rec takes as input w' (a noisy copy of w) and s. If w' is sufficiently close to w (where closeness is measured by some distance metric such as hamming distance), then Rec(w',s)=w. Now the server and I share a secret value (namely w) which we can each prove knowledge of to authenticate each other (mutual authentication).

The cool thing about this is that even if someone steals s, they won't be able to impersonate me. There are a few problems with this, however. What if the attacker modifies the copy of s that the server is storing. Could they do that in such a way that w is leaked? In the original work, there were no guarantees that this couldn't happen. Later research, however, removed this restriction by developing what is called a robust secure sketch, which is secure even in the presence of an active adversary (i.e., an adversarial controlled channel).

Keeping biometric private

The above ideas all assumed that w (and w') were kept private. This is probably not a good assumption as seen on MythBusters. So, researchers went back to the drawing board and said "Hey what if my fingerprint was my public key" and thus Fuzzy Identity-Based Encryption (FIBE) was born.

Closely related to this is Identity Based Encryption, where my identity (e.g., email address) is my public key. Someone uses my email address to encrypt a message. I then prove to a third party that I own the email address, whereupon I am able to retrieve the corresponding private key and decrypt the encrypted message. It is important to note that the sender only needs some public information from the third party to enable her to encrypt messages to any identity. The receiver must at some point (either before or after the encrypted message is actually sent) retrieve his private key.

FIBE builds upon this idea for fuzzy identities. You read my fingerprint (w), I use w' to get my private key and as long as w and w' are close enough, I am able to retrieve the message you send to me (I still have to contact the third party at some time though). An authentication protocol could be built on this so that I need not keep my biometric private.

The major problem with this system (and IBE in general) is the requirement of a third party and the fact that that third party can impersonate me once they have seen a copy of my biometric. The latter problem can be removed by having multiple third parties who all contribute to the process. Thus, no single one can impersonate me. But, then I have to contact multiple people in order to encrypt or decrypt messages.

Application

I'm not sure if any commercial products implement these ideas. So, I cannot speak to commercially available products, but if you are not limited to commercially available products, you could implement these systems yourself and they would probably be pretty secure.


(SoHo) Multi-Factor Authentication for Remote Desktop Gateway

We're running a TSG with client certificates configured to allow users to connect to their desktops. As long as you allow port 443 and properly configure the resource access policy, it works. There's a tutorial on technet on how to achieve this.

However, we're only using it for a small number of people, and we've not run into any of the licensing issues that I think sdnelson mentions. I would check this out before progressing any further.


RSA insensitive and extractable private key export from SoftHSM 2

First of all, the template you are using in EJBCA is kind of strange. I assume that this template is used to generate a key pair for a Certificate Authority.

attributes(*, CKO_PUBLIC_KEY, *) = {
  CKA_TOKEN = false ==> The public key will be generated on the HSM not be stored in the HSM (lost once the session is closed)
  CKA_ENCRYPT = true . ==> The public key is usable to encrypt (not necessary for a CA)
  CKA_VERIFY = true ==> The public key can be used to verify signature (which is required for a CA)
  CKA_WRAP = false . => The public key cannot be sued to wrap another key (also normal)
}

attributes(*, CKO_PRIVATE_KEY, *) = {
  CKA_TOKEN = true ==> The private key will be stored on the HSM
  CKA_PRIVATE = true ==> This is a private key
  CKA_SENSITIVE = false ==> This means that the object is readable from the HSM if you have the associated PIN. This would be insane for private key of a Certificate Authority
  CKA_EXTRACTABLE = true ==> The key can be extracted but it must be wrapped with another key
  CKA_DECRYPT = false ==> The key cannot be use to decrypt data
  CKA_SIGN = true ==> The key can be use to sign data (required for a CA)
  CKA_UNWRAP = true ==> the key cannot be used to wrap another one
  CKA_DERIVE = false  ==> the key cannot be used to perform derivation
}

With such a template, you should be able to read all the PKCS#11 of the private key (CKA_SENSITIVE is set to false) directly using PKCS#11, no need to use our key extraction tool which should also work as the attribue CKA_EXTRACTABLE is set to true.

Here is what the tool does:

Step 1: Generating a non persistent AES key in the HSM
Step 2: Wrap any private key with the CKA_EXTRACTABLE attribute with the key generated step 1
Step 3: Unwrap the keys wrapped during step 2 with the key generated step 1.

The fact that you are getting a CKR_MECHANISM_INVALID error mainly mean that SoftHSMv2 does not support the wrapping mechanism the tool is program to use.

When I developed this tool, I tested it on a Atos Proteccio HSM.

It seems that it is not working on a SoftHSMv2.

Here is the output I get using test mode:

./pkcs-11-key-extractor -l /usr/local/lib/softhsm/libsofthsm2.so -s 1598976893 -p 1234 -t                             pantin@pantinmbp
[*] PKCS#11 Key Extractor - Release 1.0
[*] Registering PKCS#11 Module '/usr/local/lib/softhsm/libsofthsm2.so'
[*] Opening session on slot '1598976893'
[*] Generating Test RSA key pair (CKA_EXTRACTABLE: TRUE, CKA_WRAP: FALSE, CKA_UNWRAP: FALSE)
[*] Generating Test RSA key pair (CKA_EXTRACTABLE: TRUE, CKA_WRAP: FALSE, CKA_UNWRAP: TRUE)
[*] Generating Test RSA key pair (CKA_EXTRACTABLE: TRUE, CKA_WRAP: TRUE, CKA_UNWRAP: FALSE)
[*] Generating Test RSA key pair (CKA_EXTRACTABLE: TRUE, CKA_WRAP: TRUE, CKA_UNWRAP: TRUE)
[*] Generating Test RSA key pair (CKA_EXTRACTABLE: FALSE, CKA_WRAP: FALSE, CKA_UNWRAP: FALSE)
[*] Generating Test RSA key pair (CKA_EXTRACTABLE: FALSE, CKA_WRAP: FALSE, CKA_UNWRAP: TRUE)
[*] Generating Test RSA key pair (CKA_EXTRACTABLE: FALSE, CKA_WRAP: TRUE, CKA_UNWRAP: FALSE)
[*] Generating Test RSA key pair (CKA_EXTRACTABLE: FALSE, CKA_WRAP: TRUE, CKA_UNWRAP: TRUE)
[*] Found 4 RSA private key(s) with CKA_EXTRACTABLE set to TRUE
[*] Generating an in memory (CKA_TOKEN: FALSE) 256 bits AES key
[*] Extracting RSA Private Key (CKA_EXTRACTABLE: true) with modulus '9D:89:CF:B3:32:B3:8E:50:31:32:33:2C:BC:2C:77:8A:8B:87:70:2C:85:3F:80:0B:32:2A:AB:26:20:52:F8:0F:BB:63:88:14:7C:E0:52:C3:46:BA:80:AA:56:29:06:48:D3:3A:4C:13:5E:FC:D2:93:FF:3E:DD:BC:3A:E7:75:0A:10:C4:AF:B4:29:31:85:11:03:73:EF:52:08:3D:AC:CC:81:5F:C9:77:23:68:6D:68:BC:5D:79:7A:F1:78:DA:AB:7B:50:35:EE:70:DF:E9:37:27:D1:C9:48:ED:03:B0:25:05:01:B0:EE:79:E9:63:6C:64:66:A8:4E:8A:EE:A3:E4:8B:1B:D4:63:17:8E:E9:65:B8:B9:2E:7A:76:2E:51:CF:9D:5E:CB:9D:BA:DD:3B:1D:DB:30:A9:A8:40:BE:F2:58:46:EE:9F:D2:D8:12:95:40:88:B8:D6:73:64:17:60:74:22:33:DB:18:15:6C:00:E0:B7:EB:DA:FC:F8:2F:95:A6:DE:D8:91:6D:67:51:5E:67:FB:DD:C8:4A:0F:3A:B8:BA:07:E5:B4:F1:69:E9:A9:8E:E5:98:97:69:05:D4:63:75:2D:52:DA:FF:EF:3A:DC:63:4F:A6:59:18:1D:87:E3:39:7B:3B:55:5A:D3:8E:26:5D:A9:62:72:2E:7C:A7:A2:91'
[!] Error extracting private key: 'CKR_MECHANISM_INVALID'
[*] Extracting RSA Private Key (CKA_EXTRACTABLE: true) with modulus 'B7:3E:DA:3C:0C:40:A8:59:D5:FB:30:A9:25:6E:14:55:48:BD:7A:82:85:3E:CE:51:DF:A0:7F:9E:95:98:39:5B:CB:1E:6B:92:F4:C9:39:0D:E9:6C:53:B0:DE:C8:2B:19:37:F6:21:F1:90:14:24:E0:B0:32:FB:F6:7D:31:C1:EF:CD:11:1C:4D:5F:CA:90:67:2C:EB:BA:A8:25:8F:D3:DF:9F:0A:4C:F9:30:94:AA:05:9C:E1:5E:28:D2:F6:95:9E:5D:88:6E:D1:81:7D:C2:50:A3:45:F4:1D:E3:6F:22:55:C3:34:83:DA:9D:15:36:B9:B3:8C:8D:AC:1C:B4:29:62:51:15:30:97:62:E5:CE:42:AB:FB:A5:72:F6:77:50:A0:65:0C:AC:7F:3D:70:1C:F5:F0:76:21:AF:2F:B5:5D:63:1E:7D:2D:24:9C:D5:A3:24:20:64:0B:29:82:96:65:79:04:75:C3:6B:02:01:8D:4E:5D:C2:BF:8F:E6:D0:FA:7B:D0:34:59:D5:E5:77:4E:7F:01:FC:D1:2B:48:A7:3B:DB:6C:9A:45:CE:44:1A:FB:88:A3:34:4D:13:F2:8B:14:9A:11:5E:FF:1C:1C:E9:F7:95:46:AE:C0:4E:7F:8A:04:68:4F:23:8A:83:8D:81:6A:11:C6:C4:2A:36:EB:3A:4D:47'
[!] Error extracting private key: 'CKR_MECHANISM_INVALID'
[*] Extracting RSA Private Key (CKA_EXTRACTABLE: true) with modulus 'D4:11:96:CA:68:CE:A0:A2:0E:E7:B6:91:28:33:10:E2:21:A2:27:80:46:50:13:44:8B:27:56:D9:41:95:48:7B:14:F7:18:4A:AA:03:3C:79:DF:C6:11:84:CB:30:EC:5D:B0:20:A1:35:57:0D:6F:4A:21:29:77:23:94:51:B2:52:B7:1D:E8:04:68:5A:B9:1C:6C:B3:57:27:84:8E:A9:37:BC:9D:0F:D3:3E:DE:68:9C:14:29:55:F8:19:E4:9F:77:57:AD:E3:3D:69:64:1B:00:1D:25:9F:1F:58:C7:48:62:62:F8:D9:B8:48:96:F1:76:71:CB:FA:A9:95:4C:EA:D5:57:48:8A:56:EE:B8:9E:35:82:00:2C:49:6B:10:9E:FA:66:94:DE:46:E6:DC:BC:6E:6A:52:CC:70:FE:ED:E7:AC:A7:6E:54:07:65:F7:9F:92:C9:30:3A:57:F4:AE:91:5D:3F:D9:53:93:5B:D0:CB:A8:D7:73:C7:2A:92:63:54:26:1A:AB:BE:C5:F6:9F:EE:EC:21:16:90:DF:DC:45:39:7D:6E:C7:83:0A:A7:74:33:34:B3:9C:7F:82:74:5C:13:A7:83:1D:28:6D:57:11:51:5F:D7:09:59:7B:7B:2A:E2:DD:84:A8:66:B5:1A:50:9F:91:BF:FE:23:94:29:BF:05:0D'
[!] Error extracting private key: 'CKR_MECHANISM_INVALID'
[*] Extracting RSA Private Key (CKA_EXTRACTABLE: true) with modulus 'AD:C9:0B:06:53:6B:D3:47:F2:C2:16:F6:48:85:31:7F:FD:B4:2B:F0:E2:73:87:0B:FE:34:59:75:8A:A6:95:E1:16:B7:A7:B3:75:B2:E5:69:AE:5F:47:5D:56:D7:3F:2D:14:1B:46:C1:5E:5A:ED:FD:28:6F:76:EF:4E:16:FC:CD:35:54:A2:36:52:89:80:DA:87:55:AF:BF:69:FA:FC:2C:0F:99:8C:27:DF:32:96:72:EC:AA:A3:72:9E:78:05:99:68:D5:18:70:15:C0:18:F1:C0:1E:4A:E6:BF:93:C3:12:D1:80:6F:71:1E:66:EB:39:DD:56:1B:A1:08:2B:66:6D:40:67:EF:16:15:1F:14:73:C6:66:20:46:11:57:AC:15:4F:45:FE:89:83:A3:B0:7D:5B:2E:4D:5F:8C:1F:7B:D3:5E:85:F3:61:0A:AD:86:B2:2E:03:AA:2D:6A:CC:39:7B:3E:0E:65:85:6B:8D:5B:71:F8:5C:D7:A0:C5:8B:E2:B5:9A:B4:0C:C6:C1:C1:ED:D5:D0:00:53:E3:08:41:B0:6F:1D:62:66:11:FD:C4:63:2C:B0:CC:EB:24:9B:AD:C5:2D:5E:4C:E1:C4:4B:F8:9C:31:A3:D0:B3:C6:9B:BA:2A:2B:7B:5F:35:4E:CA:3B:DB:9E:F2:90:A7:6B:C0:DF:7C:3B'
[!] Error extracting private key: 'CKR_MECHANISM_INVALID'
[*] Closing session on slot '1598976893'
[*] Unregistering PKCS#11 Module '/usr/local/lib/softhsm/libsofthsm2.so'

If you look at the code of the tool, you will see that the key is wrapped using the 'CKM_AES_CBC_PAD' mechanism.

If you list the mechanisms supported by SoftHSMv2:

pkcs11-tool --module /usr/local/lib/softhsm/libsofthsm2.so -M                                                         pantin@pantinmbp
Using slot 0 with a present token (0x5f4e737d)
Supported mechanisms:
  MD5, digest
  SHA-1, digest
  SHA224, digest
  SHA256, digest
  SHA384, digest
  SHA512, digest
  MD5-HMAC, keySize={16,512}, sign, verify
  SHA-1-HMAC, keySize={20,512}, sign, verify
  SHA224-HMAC, keySize={28,512}, sign, verify
  SHA256-HMAC, keySize={32,512}, sign, verify
  SHA384-HMAC, keySize={48,512}, sign, verify
  SHA512-HMAC, keySize={64,512}, sign, verify
  RSA-PKCS-KEY-PAIR-GEN, keySize={512,16384}, generate_key_pair
  RSA-PKCS, keySize={512,16384}, encrypt, decrypt, sign, verify, wrap, unwrap
  RSA-X-509, keySize={512,16384}, encrypt, decrypt, sign, verify
  MD5-RSA-PKCS, keySize={512,16384}, sign, verify
  SHA1-RSA-PKCS, keySize={512,16384}, sign, verify
  RSA-PKCS-OAEP, keySize={512,16384}, encrypt, decrypt, wrap, unwrap
  SHA224-RSA-PKCS, keySize={512,16384}, sign, verify
  SHA256-RSA-PKCS, keySize={512,16384}, sign, verify
  SHA384-RSA-PKCS, keySize={512,16384}, sign, verify
  SHA512-RSA-PKCS, keySize={512,16384}, sign, verify
  RSA-PKCS-PSS, keySize={512,16384}, sign, verify
  SHA1-RSA-PKCS-PSS, keySize={512,16384}, sign, verify
  SHA224-RSA-PKCS-PSS, keySize={512,16384}, sign, verify
  SHA256-RSA-PKCS-PSS, keySize={512,16384}, sign, verify
  SHA384-RSA-PKCS-PSS, keySize={512,16384}, sign, verify
  SHA512-RSA-PKCS-PSS, keySize={512,16384}, sign, verify
  GENERIC-SECRET-KEY-GEN, keySize={1,2147483648}, generate
  DES-KEY-GEN, generate
  DES2-KEY-GEN, generate
  DES3-KEY-GEN, generate
  DES-ECB, encrypt, decrypt
  DES-CBC, encrypt, decrypt
  DES-CBC-PAD, encrypt, decrypt
  mechtype-0x1100, derive
  mechtype-0x1101, derive
  DES3-ECB, encrypt, decrypt
  DES3-CBC, encrypt, decrypt
  DES3-CBC-PAD, encrypt, decrypt
  mechtype-0x1102, derive
  mechtype-0x1103, derive
  mechtype-0x138, sign, verify
  AES-KEY-GEN, keySize={16,32}, generate
  AES-ECB, keySize={16,32}, encrypt, decrypt
  AES-CBC, keySize={16,32}, encrypt, decrypt
  AES-CBC-PAD, keySize={16,32}, encrypt, decrypt
  mechtype-0x1086, keySize={16,32}, encrypt, decrypt
  mechtype-0x1087, keySize={16,32}, encrypt, decrypt
  mechtype-0x2109, keySize={16,2147483648}, wrap, unwrap
  mechtype-0x210A, keySize={1,2147483648}, wrap, unwrap
  mechtype-0x1104, derive
  mechtype-0x1105, derive
  mechtype-0x108A, keySize={16,32}, sign, verify
  DSA-PARAMETER-GEN, keySize={512,1024}, generate
  DSA-KEY-PAIR-GEN, keySize={512,1024}, generate_key_pair
  DSA, keySize={512,1024}, sign, verify
  DSA-SHA1, keySize={512,1024}, sign, verify
  mechtype-0x13, keySize={512,1024}, sign, verify
  mechtype-0x14, keySize={512,1024}, sign, verify
  mechtype-0x15, keySize={512,1024}, sign, verify
  mechtype-0x16, keySize={512,1024}, sign, verify
  DH-PKCS-KEY-PAIR-GEN, keySize={512,10000}, generate_key_pair
  DH-PKCS-PARAMETER-GEN, keySize={512,10000}, generate
  DH-PKCS-DERIVE, keySize={512,10000}, derive
  ECDSA-KEY-PAIR-GEN, keySize={112,521}, generate_key_pair, other flags=0x1900000
  ECDSA, keySize={112,521}, sign, verify, other flags=0x1900000
  ECDH1-DERIVE, keySize={112,521}, derive

You can see that the 'AES-CBC-PAD' mechanism is only usable to perform encrypt and decrypt operation.

Here are the mechanisms which could be used to wrap/unwrap a key in SoftHSMv2:

pkcs11-tool --module /usr/local/lib/softhsm/libsofthsm2.so -M | grep wrap                                             pantin@pantinmbp
Using slot 0 with a present token (0x5f4e737d)
  RSA-PKCS, keySize={512,16384}, encrypt, decrypt, sign, verify, wrap, unwrap
  RSA-PKCS-OAEP, keySize={512,16384}, encrypt, decrypt, wrap, unwrap
  mechtype-0x2109, keySize={16,2147483648}, wrap, unwrap
  mechtype-0x210A, keySize={1,2147483648}, wrap, unwrap

This mainly means that to make our tool work with SoftHSMv2, you would have to modify it to generate, wrap and unwrap the key with a RSA key pair.

Feel free to contact me directly on may email to explain me why you want to do that and we will see what can be done.


Prevent password reusing across different sites

Type your password, be sure to include word "honey" in it. Is it reasonable?

No, it's not.

Random password generators might not support the addition of a specific word.
It's harder to remember for users who don't use password managers.
It encourages users to choose a shorter password than they could have used without the condition, just because they want to remember it easily.


Closed source binary blobs in chipsets - privacy threat?

Summary:

There's probably some BS marketing going on, but on the whole they probably are making the more privacy-respecting laptop they can. Other answers mention other brands of privacy-focused laptops that avoid Intel chips in favour of 100% libre hardware, but you take a big performance and cost hit for doing it, because, well, Intel is the market leader for a reason.

Who do you trust?

Unless you go out into the woods with a hatchet and build yourself a life, you've got to place trust in somebody. Based on the descriptions on their page, the company Purism seems like a reasonably good group to place trust in (which you seem comfortable with if you're already considering buying their laptop). They clearly put a lot of scrutiny on their component suppliers with regards to privacy. Assuming of course that it's not all B***S***t marketing, which I have no way to know for sure. (See the "Additional Thought" at the bottom for more on this.)

Intel

As for binary blobs and Intel, this is actually a deeper question than you realize. "Binary Blobs" refers to software that's provided to you in binary (executable) form, but you have no access to the source code, or any good way to inspect it. Intel is a hardware manufacturer, so while they may have some binary blobs of software, what about hardware that's provided to you in chip form with no access to the designs? Do you think Intel allowed Purism to inspect the blueprints for all of the chips on an i5 board? Of course not, that's billions of dollars worth of intellectual property!

This debate around Intel, privacy and black-box hardware is currently a hot-topic with Intel's RdRand instruction - an assembly instruction for retrieving a random number from an Intel hardware-RNG chip on the motherboard. I was recently at a crypto conference and overheard one of the designers of the RdRand chip having a discussion with another attendee that went something like this:

  Attendee: "RdRand is a blackbox chip. Will you release the source designs for security audit?"

  Intel engineer: "No, of course not, that's protected intellectual property."

  Attendee: "Intel is in American company, how do we know the American government hasn't forced you to include backdoors?"

  Intel engineer: "Well, I guess I can't prove it to you, but I designed it and I can assure you that there aren't any."

  Attendee: "Forgive me if that's not good enough. I'm going to continue doing random numbers in software."

  Intel engineer: "Your loss, I guess."

So, should we trust them?

At the end of the day, unless you live in the woods, you have to trust somebody. I personally think the Intel corporation is very security-aware - having attended multiple crypto conferences with them, and while they are under American law (I'm not American BTW), I think they are at least as trustworthy as any other closed-source hardware vendor. Ken Thompson's 1984 paper "Reflections on Trusting Trust" showed that trojans can be injected at the compiler level in a way that's almost impossible to detect, so even inspected open source code is not guaranteed to be trojan-free.

At the end of the day, you're got to trust the people, not the code. Do you trust Intel? Do you trust Purism to be scrutinizing their suppliers as well as they are able to? Nothing will ever be 100% provably secure, but Purism's products are certainly better than your standard laptop from Best Buy.

Additional thought:

The Purism Librem product pages say:

  Welcome to the beautiful laptop that was designed chip-by-chip, line-by-line, to respect your rights to privacy, security, and freedom.

"Line-by-line" .... right, sure. The linux kernel itself is about 16 million lines. The Librem ships with either their Debian-based PureOS, or Qubes OS, which will both contain tens of millions more lines, plus bootloaders and firmware, plus all the apps in the Debian repositories. You want me to believe that Purism's 6 developers have personally inspected every single line of code for insidious, hard-to-catch backdoors? And have also inspected all the compilers used looking for self-replicating trojans? Please. Over-zealous marketing.

That said, if you take Ken Thompson's "Trust the authors, not the code" philosophy, and we decide that we trust the Debian devs, and the Intel engineers (I have decided to trust them out of convenience), and we trust Purism to apply the "Trust the people, not the code" philosophy appropriately, then we're probably OK.


Certificate Practice Statement (CPS) without CP (Certificate Policy)?

Your other question seems to suggest that a CA writes the CP, but this isn't the case.

A CP is written by the authority responsible for the PKI as a whole - usually called the PKI Management Authority (PMA).  It is the PMA that owns the trust relationships between the entities within the PKI and it is the PMA which therefore does everything it can to ensure that trust isn't lost.  As part of this it sets down rules (policies) which any Certification Authority has to follow if it is to be part of the PKI.

Once the PMA has written the CP, any Certification Authorities that hopes to issue certificates on behalf of that PMA must design the CA in line with the CP.  Once that's done it must write a Certification Practice Statement that demonstrates how it is following the CP.  Note that a well written CP will have audit policies that allow CAs to be checked for amongst other things, CP compliance.

A CPS without a CP is pointless.  Without a CP the content of the CPS could be absolutely anything and it wouldn't be breaking any policies.

For example, section 6.2 covers the protection of private keys.  Without a CP your CPS could say something to the effect of:

  the Root CA private key is held on a USB stick stored in the stationary cupboard

The statement is irresponsible; but it doesn't break any laws, or policies.

However, if your management deem the above unacceptable and that the private key should be stored in a FIPS-140-2 Level 3 Hardware Security Module, then that what should be in section 6.2 of your CP.  Once that's there, the previous CPS statement breaks policy and isn't acceptable.  Attempting to submit a CPS with the above statement would result in rejection by the PMA and consequently the CA wouldn't be allowed to join the PKI.

It may be tempting to only write a CPS and submit it for review by either peers or management.

If your CPS is returned without any comments and accepted, you have to ask yourself whether the reviewers know their subject, or whether you've over engineered your CA thereby wasting time and money.

If your CPS is returned with comments (maybe suggesting how the private key should be stored amongst other things?) then these comments are the beginning of a CP.  However, instead of many iterations of this review process and maybe heated discussions/arguments/firings, it would be much simpler if a senior authority (the PMA?) writes down the rules of running the PKI which all CAs must follow.  In the long run, a CP will make the process of writing a CPS much simpler - after all, all the subjects need to be discussed at some point, so do it before designing your CA.

Finally, remember that there is only one CP covering all the authorities (CAs, RAs, VAs) in the PKI. Each CA (and possibly RA and VA if they're separate entities to the CA) writes a CPS to state how they're following policies.

As a minimum, Acme Inc will have a single Acme CP (written by the PMA), followed by the Acme Root CA CPS (written by the operators of the Root CA) and the Acme Issuing CA CPS (written by the Issuing CA operators).


What is the relation between ANSI and ISO regarding ISO 27000?

ANSI stands for American National Standards Institute

ISO stands for International Organization for Standardization

ANSI is the American representative of the ISO body.

So, yes, ISO is the umbrella, but in the US, ANSI is the representative.


Authentication between web services within the same project

If your system is relatively small and you're not too worried about man-in-the-middle attacks, then a pre-shared key is the simplest way to go. Think of it like a password that one server uses to recognize another. Ideally each server has its own password which is used to identify itself with others. If you need to, you can avoid disclosing the password while at the same time proving knowledge of it by using a challenge-response hashing mechanism.

If your system is large or adding and removing nodes happens often enough to make pre-shared keys difficult to maintain, then I'd recommend building your own PKI. This is simple enough to do with SSL certificates: just generate a central signing certificate and mark it (and it alone) as trusted to all of your servers, and issue each server/service its own certificate which it uses to identify itself with others. Use the subject field of the certificate to tie the certificate to the server/service, and of course sign each with your signing cert. SSL does provide for mutual authentication of both client and server for a single connection, so you can use completely off-the-shelf components for this. If necessary, you can include short expiration times and/or use revocation to enhance security if you're worried about keys falling in to the wrong hands.


I want to pass an encrypted password to another program to decrypt

At the high level, it sounds like you're trying to get both programs to agree to use the same password.  You might then be muddying the issue by adding a second constraint to this, which is "how do I move the password securely from program 1 to program 2?"

This is the classic problem that Secrets Management solutions were developed to handle.  Have you considered using a secure storage program, like Hashicorp Vault?  You can give both programs 1 and 2 access to the same vault instance.  Then, your secrets are always stored in the vault, and only taken out by the programs as needed.


With RSA, can one ensure that two entities will not have the same private key?

Probability.

When generating a 1024-bit RSA keypair, one of the first jobs is to pick a pair of primes p and q such that the product of those numbers (i.e. p multiplied by q) is 1024 bits in size. The simplest way to do this is to pick both values to be somewhere around 512 bits in size each, as 2512 × 2512 = 21024. Note that I'm picking 1024-bit as it's now considered to be the lowest acceptable key size, in which you're going to have the highest likelihood of prime collision.

Now, if we assume that only 512-bit values are used for p and q, we can now estimate how many primes there are in that range. I discussed this in an answer to another question about RSA, but I'll re-iterate here. The prime counting function allows us to estimate the number of primes in a given range. It isn't really defined, as it's just an estimation, and there are various ways to compute it. The simplest and roughest way is simply π(x) = x / ln(x), where π is the PCF and ln() is natural log. As I explained in the linked answer, there are likely somewhere around 1.885×10151 prime numbers in the range 2512 < n < 2513.

This means that, assuming an ideal implementation, the chance of picking equal p or q values in two independently generated RSA key pairs is roughly one in...

  18,850,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000

That's slightly less likely than winning the jackpot on the UK national lottery 21 draws in a row (13,983,81521 = 1.143×10150).

This is all assuming that the implementation is ideal. However, this isn't always the case. For example, there used to be a bug in OpenSSL that caused uninitialised stack data to be used as the random pool for generating RSA primes, which meant that the actual number of possible outputs from the RNG was quite small. The resulting key pairs are now blacklisted from most implementations to prevent exploitation. Another example is that in many embedded devices (e.g. firewall appliances, routers, etc.) certain cryptographic values, such as SSH session keys, are generated early on in the system boot process, when there isn't much entropy available. This leads to a situation where the number of possible generated keys is significantly lower than you might expect, potentially leading to prediction attacks.

The tl;dr is that the key space is so large that randomly selecting two equal primes (p or q) when independently computing two RSA key pairs is phenomenally unlikely.


Are mkpasswd SHA512 hashes secure for the public?

The key difference here (no pun intended) is that the key includes a significant amount of entropy (i.e. it is random). Passwords are often quite terrible, commonly having under 30 bits of entropy. 30 bits is easily brute-forceable, so password hashes are designed to be slow (you specified salted SHA512, but you omitted the number of rounds), making the brute-force take longer. Despite this mitigation poor passwords will still be broken quickly.

Without a salt an attacker could use precomputation in the form of a rainbow table. That way, they could spend a bunch of time doing work so that when they do discover the hash value they can break it very quickly. The use of a (sufficiently long and random) salt prevents this, so that the attack can only begin the moment the hash is exposed.

So you are correct, this is a bad idea unless it is your password and you generated it with over 100 bits of entropy (in which case it's more like a key than a password).

It should also be noted that SHA-512 with the default of 5,000 rounds is not very good. It's not nearly as bad as a single round of MD5, but most computers nowadays can do over 2,000,000 rounds in under a second. You could expect a motivated attacker targeting a 5,000 round SHA-512 password to do millions to billions of guesses per second.


A simple question about entropy and random data


What advantages would client-side certificates have over signature based auth such as Oauth2 or HMAC for HTTP Requests?

Windows has a pretty good story for the management of certificates and private keys with the certificate store and key store.  Many (most? all?) cloud services have a pretty good story for the transportation of certificates so they can be used for SSL/TLS.  I don't know of any particularly good management for HMAC keys (the closest thing being a general settings transportation system).

Certificates have enough metadata that a system/service admin/(dev)op can see which one is being used to help diagnose why something isn't working, and it can be done on the non-sensitive portion of the data (the public key).  An HMAC key, on the other hand, either has to be revealed in its entirety and compared byte by byte (or hex nybble by hex nybble, etc) or have some form of hashing applied to it to obfuscate the value but still allow the value to be compared across machines.

These reasons, mainly, are about "ease of management" on the part of the client.  Being able to be used correctly is an important aspect for security, but it's a less obvious one.  You still need to have an appropriate registration model for the certificates, either by using your own CA to control subject naming (which requires revocation as a cancellation mechanism) or by storing the certificate (or public key) the same way you would have stored their HMAC key (which can avoid the need for revocation)... you want to only let the appropriate certificates authenticate a particular user.

Windows private key management allows for applications to use the key without being able to export it, meaning that system operators that only have access to running instances can't then act as the system at home.  An HMAC key has the problem that "use it" and "exfiltrate it" are the same permission.  This is an operational security problem.  An overly loggy client application can easily get itself in trouble with logging the HMAC key; but for a cert it would require a) the private key permissions to allow exporting the key material and b) someone going out of their way to move the key object into a loggable form.

Oh, and client auth certificates can also have their private keys on an HSM, making exfiltration even harder, and depending on what your API allows some of your callers may feel that they need HSM security.

So: mostly ease of management, and a couple of op-sec reasons.


What to take into account when validating file upload

I think you're not missing something, and in my opinion there is no way to testify that an image is 100% clean unless you analyze it by hand, I'd say adding MIME validation (in both client and server side) is a step to do before validating against magic number, this will eliminate some script kiddies :)

Now if you really want to reduce your attack surface, you can first reencode the image into a simple/poor/trivial format,  in a sandboxed environment with a minimum privilege and no access to unnecessary syscalls. Once you get the reencoded file, you can re-reencode it to a more common format (png/jpeg..) At this stage you can trust the input since it comes from your system, and use stream or maybe memorystream to convert your image (try and catch everything !)


Check photos for geotagging and remove lat/long data

I have used exiftool for this kind of work. It basicly lets you review and edit any meta information in your pictures.

I used this to exploit a image service which echoed the geo details back at the user. I filled the images geo data with XSS and attacked other users viewing the picture.


I came up with this scheme:

Digest authentication is defined in RFC 2617 so please refer to this documentation instead of coming up with your own scheme.

  It may also be vulnerable to replay attacks...

The nonce set by the server is used to defend against replay attacks, i.e. only replies are accepted which match the unpredictable nonce.

  What could the flaws be then? I am not confident that the scheme that I used is flawless.

While Digest solves the problem of authenticating the client over an insecure channel it makes it necessary to store the passwords at the server in plain or in some equivalent form in order to verify the data sent by the client. This shifts the vulnerability problem from the data transport to the server. And in effect it enables an attacker to not compromise a single account but zillions at once.

Which means you should better use TLS to secure the channel and keep the password stored in a secure in irreversible form, so that an attacker cannot compromise accounts easily and en mass. Additionally this solves the problem of missing identification of the server.


Inject JavaScript code into websites requested by an Android app?

My best bet would be to just browse the web through a proxy that injects the script for you. On a desktop you can just use the developer console or a browser extention, but that's not an option on mobile.

Note that this is not really a way to "hack" someone, since the only person it affects is yourself.


What you are looking for is a "packet capture". You want to capture all traffic on port 25 from your network and see:

volume of traffic
type of traffic
destination

If all looks ok, then it's not malware.

A small ISP blaming the customer and invoking malware/virus/sunspots/aliens as the culprit is nothing new.

Aside from the above, though, this really isn't a security concern but a networking troubleshooting concern.


Resources for pentesting cloud based services/web-apps?

you can try this article at:
cryptome.org/2013/07/cloud-pentest.pdf

also this video might be helpful though it is from a less technical viewpoint: https://www.youtube.com/watch?v=nXiv8VFOHcA

lastly I would recommend looking at this article as it might give you some good ideas:
www.mecs-press.org/ijcnis/ijcnis-v3-n3/IJCNIS-V3-N3-1.pdf

pen-testing cloud based services is still a fairly new subject so naturally there are limited resources :)


Why isn't HTTPS enough to defeat an evil twin attack?

In general, HTTPS should be enough as long as you don't do anything crazy like installing extra trusted root certificates, or bypassing warnings because you want to see the page.

But, that assumes only HTTPS sites are visited, and there is NO OTHER network activity. How many apps do you have that use the network in the background? Do you know if all of them encrypt their communications? How often do you explicitly type https://? If you browse the web normally you'll be vulnerable to sslstrip.

So yes, in theory just visiting HTTPS site is ok, but if you're on a malicious network, you probably don't want to risk something slipping by you.


Can a Windows or Linux password be brute-forced on a public network?

If you assume that all passwords on the system are strong, then no.

The definition of a "strong" password is that the time to complete a guessing attack, whether brute force or with a "common passwords" list is long with respect to the exposure.

Unless you live in the hotel, you'll be gone (and the exposure will end) before an attacker could have acquired your password through a brute force attack.  (Um, unless the attacker has physical access to the machine, which wasn't part of the question.)  On the other hand, if your password is cracked by brute force, it wasn't "strong."  There's a nasty amount of circular reasoning in there.  Let me see if I can get rid some of it.

The strength of a password is measured in bits of entropy, or randomness.  If your password is on the list of 500 most common passwords, you have about 9 bits of entropy because log2(500) is about 9.  Put another way, 29 = 512.  If you use a password that is five Dicewords, you'll have about 55 bits of entropy because each word is drawn from a list of about 2,000 words and log2(2000) is about 11. (211 is 2048.)  You get eleven bits of entropy for each of the five words, total 55 bits of entropy.

If one can make G guesses per second against a password with n bits of entropy, then the average time to guess is 2n-1/G because, on the average, the attacker will "hit" about halfway through the possible values.

So, an example: a password with 28 bits of entropy and an attacker can make 210 guesses per second, assuming an online attack.  (Offline attacks can be much faster.)  That will take about 227 guesses, or 227-10 seconds, or about a day and a half.  If you have 55 bits of entropy in the password, that's 244 seconds, or about 557,000 years.

Now you have a fairly rigorous definition of "strength" and can figure out how strong your password must be to withstand a sustained attack over a three-day hotel stay.  (There's a pretty big assumption about G in there, though.)

Edit: This answer addresses a brute force attack on the operating system's login interface, which is, I think, the question.  There are many other kinds of attacks.


how to identify whether my page is phished or normal page?

Doing a test login with fake credentials I think is the best way. You could examine the Net using debuggers as FireBug (mozilla plugin) or Chrome debugger to look where the information is being sent, or if you are being redirected to other web etc.

Also you should pay attention to the domain, thisisalongdomain.com and thisisalongdoman.com might seem equal, but if you look carefully you will notice the difference.

Other way is searching it on google (or other search engine). Usually the real website would appear before, (but this is not 100% secure). Or you might even find that that phising web have been reported.

Usually checking the https is a good option, but if a trusted CA gets compromised, bear in mind that you could end up in a https web that is not the real web.

Edit: For users with not enough IT knowledge, I recommend not to trust links on unsafe environments, like an email from an unknown sender, a chatroom or a forum since most phising attacks rely on those mechanisms to succeed. I will be surprised if a phising website gets to the firsts possitions of a search engine...

Apart from paying attention to visible (at first sigh) things as the url, as I said before, or the httpS as vignesh said, there is little more they could do by theirown if they fall in a phising website.

I think they should totally use antivirus, nowadays they tend to warn you if a website is a phising website (at least Norton and McAfee do), this could safe lives, but of course, with new phising websites, I guess they will not warn you.


What are common/official methods of reporting spam/phishing/nasty-grams to organizations?

Most often, these kinds of emails are sent from either compromised hosts, spammer accounts at free webmail providers, or dedicated spam-spewing networks (this is called snowshoe spam). In either case, the most appropriate parties should be, and should appreciate, being contacted since it represents a threat on their network. Reporting can be tricky, however, as it is not always obvious where the message came from. The first two things you can do are send an email with an RFC5322 attachment of the email, with full headers, to

spam@access.ironport.com
spam@knujon.net (which copies all reports to spam@uce.gov)
or paste the pristine raw email, again with full headers, to SpamCop

Variations of the above that additionally flag reported mail as phishing:

phish@access.ironport.com
phishing@knujon.net (which also copies phishing reports to APWG)

The first address is used by Cisco for receiving reports of missed spam in their IronPort anti-spam solutions. They monitor this mailbox and develop signatures for reported spam. So, eventually, the specific phish you received should be caught by their spam filters.

The second address is KnujOn ("No Junk" spelled backwards), a non-profit group that collects spammer domain data and follows the money trail in an effort to actually bust domain registrars that are too spammer-friendly.

The UCE address is used by the United States Federal Trade Commission to build out investigations and cases against spammers. Again, given the highly difficult nature of performing such investigations, one should not expect results from sending messages here. However, given the effort involved, and the fact that it might be useful in going after spammers/phishers, it seems a worthwhile action to me.

The most immediately useful action is to contact the folks responsible for the source of the spam. We can use this information to locate compromised computers or accounts, open mail relays, etc, and respond in kind. Determining exactly where to send this information may be tricksome. If your organization has an Information Security office, you can fall back to forwarding said email to them for processing. Otherwise, plow through the Received: headers to determine which mail server the message originated from; the most recent of them that is beyond your organization's control is the culprit.  (Do not assume the From: header is valid.)

From that IP address or domain you can look through the registrars to determine technical contacts, and forward the message to them. If you have a domain, then you can also attempt to use abuse@. That address was partially formalized in RFC2142, but is certainly in common use.

In all cases, you really need to forward the email with full headers intact. The specifics of how one does that will depend heavily on the specific mail client, but Forward As Attachment should work in almost all cases (except Microsoft Outlook for Windows).


PCI DSS placement of puppet (or chef) server?

I worked for a QSA company for 2 years, so here is one ex-assessor vision of your case.

It is absolutely fine to use configuration management (CM) tools from the PCI DSS perspective. In short, to be OK with the standard compliance you must make this system PCI DSS compliant itself and align your configuration management and support processes with PCI DSS requirements.

First of all, deal with the PCI DSS scope. While tools such as Puppet/Chef are not directly involved in payment card data processing, they are affecting the security of such system components. It will not be considered a part of cardholder data environment (CDE), so it is not required to sit within isolated network segment. Any Puppet/Chef service dependencies that affect its own security will also be in scope of PCI DSS review. These may include: AV server, log server, authentication , version control, package repository servers and so on. So, in case you have such infrastructure within PCI DSS scope, it is a good idea to reuse it (for example, forwarding logs to already-in-PCI-scope log server).

There are generally two recommended patterns when you incorporate CM tools into your environment:

Install self-contained server within CDE and use only for the purposes of managing PCI-related system components. This way, you are minimizing impact to your existing PCI DSS scope but losing flexibility.
Use multiserver architecture and install some part of it within CDE. This way, you get more flexibility, but some systems from your “regular” non-PCI network will be in scope as well.

In any case, you should work closely with your QSA to determine if your intended scope is correctly defined and no important systems left behind.

Once you understand what changes to PCI DSS scope will be made by incorporating configuration management tools, you may plan how you’d implement technical and procedural PCI requirements for this changed scope. I will not describe process here, since it is too lengthy and is not different from what you already should be doing with your existing infrastructure anyway.

One important point that I want to note though: introducing CM tools usually greatly impacts established change management routines. Per requirements listed in clause 6.4, there are a lot of tasks one should be doing when applying changes. This means literally anything you do with the whole your CM system must be planned/tested/reviewed/approved in PCI-prescribed way. And that’s the reason why a lot of DevOps shops end up using completely isolated CM system to manage PCIDSS-related systems. Anyway, make sure you have your change management procedures updated.

I hope this helps – it is hard to address this issue and not write a lengthy paper with a lot of “if else” conditionals.


Sharing login session from one website to another?

Using something like oauth would probably be easier and safer.  The main issue with it is that you can't use the user password for user level encryption, but if that isn't needed by the site the user isn't logging in to directly, then you are fine.

You have the basic idea right, in that you want the one server to be responsible for the login and the other to trust that server, but I would suggest that you want a system that relies on trusted communication between the two servers rather than a string to validate the session.  That's basically the idea with oauth, where the one system has the other system process the login and return a validation that the user authenticated.  You could hide the oauth process because the user is already logged in to the site that will validate their identity, so it could be done behind the scenes.


Is penetration testing becoming objectively "harder" as apps/protocols/operating systems become more secure?

The objective of penetration testing is not to find vulnerabilities, and so it hasn't failed if it doesn't find any. It's to check whether or not vulnerabilities are present. It doesn't get harder if systems get more secure, it just comes up with fewer vulnerabilities. In fact, it will get easier if the list of known vulnerabilities to check gets smaller.


SSD (Flash Memory) security when data is encrypted in place

I think this question is asking a bit more about what happens when you encrypt data on a device where that data was previously unencrypted. SSD units and HDD units suffer from different possible compromises related this. This is basically referred to (at least on the venerable Wikipedia) as data remanence. That article offers lots of information about the various ways that data can remain or be leaked on hard drives.

Where the SSD presents a special problem, it also presents a new resolution: the "Secure Erase" command to compensate, just as TRIM helped compensate with deletions.

If your security concerns are sufficiently high that you're worried about the block level activity of unencrypted data, though, I suggest the following: consider any drive that has ever held sensitive data in an unencrypted state to be tainted. Use partition or device-level whole disk encryption.

This applies to HDD systems as well as SSD systems. The particular case would be an over-written file. Advanced recovery techniques have been theorized to read overwritten data (hence secure wipe pattern algorithms: DoD 5220.22-M), though that may be an artifact of lower density drives (http://computer-forensics.sans.org/blog/2009/01/28/spin-stand-microscopy-of-hard-disk-data/ and http://www.securityfocus.com/brief/888). Never the less, advanced filesystems might process an overwrite to another location, or capture snapshots of data when unencrypted.


How risky is connecting to a hidden wireless network?

The risk here is in believing that a "hidden SSID" changes anything to the security. A non-hidden SSID means that the router will shout at regular intervals "hello everybody, I am Joe the Router, you may talk to me !". A hidden SSID means that the client machine (not the attacker's machine) will shout at regular intervals "Hey, Joe, where are you ? Please respond !". Either way, assuming that the SSID (here, "Joe") is not known to any attacker would be overly naive.

A point that could be made is that when the SSID is hidden, then an attacker may assume that the SSID is valuable in some way; so, when your PC connects, your PC shows that it knows the valuable SSID, and thus is also a valuable target in some sense. Not that it would change much things in practice: attackers will attack everything in range anyway, as a matter of principle.


How to make a victim submit a post via XSS?

There is a major difference between code executed in the developer console step by step[!] and JavaScript that's part of the page:
All running JavaScript is stopped when you navigate away to another page.

But why would you bother to write JavaScript to mimic a user?

If you want to send a POST-Request (for example send something that looks like a user submitting a form) use an AJAX-POST-Request like shown in this Stack Overflow Answer


Where does the encryption happen with an encrypted VPN?

Your understanding is correct; when using a VPN, all traffic is encrypted on your laptop and remains encrypted all the way until the VPN server.

I think the wording in that answer is a bit confusing because there is more than one "network" here:

The wireless network provided by the coffee shop (wifi)
The Virtual Private Network (VPN).

Earlier in that section, @RoraZ says:

  Let's take a situation with a VPN: you have your remote laptop R and your private network gateway/secure anonymous proxy (G). Now you have a private network IP that is encrypted from R to G. A network admin sitting on G can see your plaintext.

So I think he means "VPN admin" rather than "wifi admin".

As a fun side-note (and where I thought this question was going when I first read it) is that encrypting your traffic does not fully protect you against traffic analysis. For example when using HTTPS encryption, anyone sniffing your traffic can see which web servers you're talking to (everything up until the first slash in a URL, ex security.stackexchange.com). VPNs and TOR hide this because all your traffic looks like it's going to the VPN server, and the VPN server opens fresh connections to the web servers.

Another fun bit of traffic analysis is that, even encrypted, someone sniffing your traffic can see how many packets your're sending / receiving, and the size and timestamps of those packets. This awesome paper:

Identifying HTTPS-Protected Netflix Videos in Real-Time

shows that not only can they tell from the packet size / timestamp data that you're streaming Netflix, but thanks to the way video codecs work (bandwidth spikes when the scene changes rapidly) they can actually tell which Netflix video you're watching.


Is it really Security Misconfiguration to show a version number?

The security impact of exposing the version number is that an attacker can instantly see whether your version is vulnerable to a known vulnerability. For example, jQuery before 3.4.0 is vulnerable to CVE-2019-11358, so it is useful information for an attacker to know whether your jQuery is 3.3.9 or 3.4.1.

However, with JavaScript that runs in the browser the complete source code is accessible by the attacker, so it is impossible to hide whether your jQuery is vulnerable. Even if you hide the version, the attacker can compare the code, or just try an exploit, to determine whether you are vulnerable. Hiding the version number may make it slightly more work, but realisticly it accomplishes little.

Furthermore, there are other ways to mitigate this:

Keep in the loop about security problems in the libraries you use. Subscribe to a mailing list or another publishing method for security problems.
Update the client libraries whenever a security problem is identified.

If you always have a non-vulnerable version because you update regurarly, it is no problem that the version is disclosed. And you can tell your client that this is the  way you mitigate the information disclosure.


What problems does this "recover account" procedure have?

As usual - depends on the nature of what you're protecting.  Seems decent enough for basic information.  May need more if you are writing code for something high end - like web banking.

Whenever secret questions/answers are used, the answer ends up taking the place of a password somewhere, and its easy for that to be your weakest link.  Since secret answers can easily be things that an attacker could find out by Googling the person, they can be a real risk factor - and it's hard to tread the line of questions that are so unusual that they are not relatively easy to figure out and questions that are so esoteric or non-applicable that the account owner can't answer them.

I like @Iszi's idea of letting the person write their own Q&A set - that circumvents the problem nicely.

In the case you mention if an attacker can intercept email coming from you system, then they don't need the user's account.  That means that the biggest line of defense is that shared secret.

You didn't say, but I'm assuming that all account set up and password reset happens with SSL/TLS protection, right?  If not, that would probably be the bigger problem.


First, I have an issue with nomenclature: articles like the one you linked to sortof suggest that the terms "public/private key pair" and "certificate" are interchangeable. In reality, a certificate is just the public key part of the key pair, and a .pfx file is a bundle that contains both the certificate (public part) and the encrypted private key [source].

(It grinds my gears when people talk about a "password protecting a certificate" which makes no sense since a certificate is public information! You really mean "password protecting a private key". But since the PFX format encourages people to think of it all as one bundle, I guess this is forgivable.)

Based on that article you linked, it looks like RenewCert is using the private key associated with that certificate to generate a new self-signed certificate containing the same public key as the old cert (and getting a longer expiry date on it in the process). Self-signed certs would fail in HTTPS, but your SmartClient applications should be fine with it. Certificates need to be signed by somebody's private key, so  RenewCert is using the same keypair that you are certifying to do the signature (hence "self-signed certificate").

The other way to renew a certificate is by submitting a certificate signing request (csr) to a certificate authority (CA). Unfortunately, here too you need access to the private key so you can prove to the CA that you own this key through a proof-of-possession [see RFC 4211 Section 4. and an IETF statement about POPs in CSRs].

So the answer to your question is: unless you can find a way to access that private key (by remembering the password on the .pfx file, or by finding the private key in a backup somewhere) your only option is to generate a new keypair, make a completely new certificate, and update all the applications. No way around that... the whole point of certificates is to prove that you own the corresponding private key.


When updating a subkey's expiration date, do old backups of my private master key become invalid?

The expiration date of subkeys is stored in a special kind of signature issued by the primary master key on the subkey. With other words, if you change the expiration date, no private keys are changed at all. If you can restore the public key later (for example, fetching it from the key server network), you're fine.