Reliable random seed for RNG I want to create my computer passwords with a RNG, but I am thinking about one thing: I would use python to write that script and the RNG is controlled by one seed, most likely the time. If I would generate my passwords with a RNG that is seeded with the time and someone knows about it, he could try to brute-force the generated passwords by using the time when I possibly created the passwords.

To put it short, in my opinion time is no good seed for a RNG if the output should stay secret, but what are good seeds for an RNG? I already heard of ideas like reading allocated memory (if it was just allocated, it should contain random bytes), using the current PID or using the last bits of the mouse cursor position. Which of these ideas (or other ideas) is really complete random?

This depends on the platform.

As a general case, you should consider using the OpenSSL bindings to use OpenSSL's RAND_* API. Do make sure to seed it correctly. Not reading the OpenSSL documentation will cause a security compromise on virtually all operating systems due to improper RNG seed. Even “big ones” have been bitten by this.

On Unix-like operating systems including BSD, the Hurd and Mac OS X, you should read from /dev/arandom (if it exists), or /dev/urandom (if it exists), or /dev/random (only if none of the other two exist). If none of these ① exist and ② are character devices, stop with an error to prevent compromise. You really do not want to “invent” an RNG/seeding scheme yourself!

On Windows® systems… first consider if you really want to do this. This is already a potential security compromise. Then, read from /dev/urandom if it exists (Cygwin), or use the CryptGenRandom API. I'm not sure there are Python bindings for it, but it's not hard to do in C, and can be made into a compiled Python module. Maybe with FFI…

When using OpenSSL, do consider to set RANDFILE to keep a seed across program invocations, especially on Windows®. Consider preseeding this from known good entropy. Maybe mixing stuff from random.org, randomnumbers.info or fourmilab.ch's Hotbits service (but, again, do not only take from there, as it's transmitted over the network). Be aware that the RANDFILE is not handled properly by OpenSSL by default: instead of read+RAND_add+write+close on program start, it's normally read at program start and written only at program end; this is better but only if your program (and all other programs using it) is not running more than one instance at any given time.

Do not use any of those:

Process ID
Time
Mouse position
Screen content
Content of “uninitialised” memory – it is often not uninitialised (even malloc() results, which the C library may not initialise, is initialised by the OS for the sole reason to clear what was in there before (e.g. from another process), and the simplest way to clear it is to zero it out), and if it is, this is normally Undefined Behaviour, which may lead to all sorts of mayhem

It is true that these are (some of the) input sources used by the OS and/or OpenSSL for their RNG implementations. But these people know (more or less, but a bit more than you) what they are doing, and, far more importantly, they are not the only sources. They are all not secrets, and an attacker can experiment with them. More importantly, their value range is not great. Also, do not write any “keyboard input” code (values and timing) yourself. The OS handles keypress-to-entropy conversion itself, normally. Just ask the OS for good entropy, and error out if there isn't any.

Do not use the system's hardware random number generator as only source! They can be compromised. Also, it may not even exist, or access be prohibited (think virtual machines).

Mixing any of these into a pool is good – but then again, the OS will do a much better job at that than your user-space application.


Why's the "public key block" different although fingerprint is same for gpg keys I'm new to pgp & trying to understand how it works.

nginx's signing key is listed here : https://nginx.org/keys/nginx_signing.key

It's fingerprint is : 573B FD6B 3D8F BC64 1079  A6AB ABF5 BD82 7BD9 BF62

If I search for nginx's key on pgp.mit.edu, I get a different looking ascii key whose fingerprint is the same as above.

Why are the "public key block" parts different although the keys are same ?

The fingerprint of a key is calculated over the parts of it that are relevant to ensure you have the right public key.

But a PGP public key can contain more information than that; for example, it can contain a portrait image, it can contain signatures of people who trust your key, their e-mail addresses and so on. The order of these elements may change without changing the fingerprint, and whether or not a key contains an image does nothing to change the fingerprint, because the portrait or the order in which these elements are stored isn't relevant for authenticating the key.

So it's probable that the keyserver changes some of the non-relevant parts of the key; so you get another key block, but the same fingerprint.

Imagine someone messed with Bob's key on the keyserver to change the portrait picture contained in it. The fingerprint would stay the same because even with the wrong portrait, if Alice used the key to encrypt a message to Bob, it could still only be decrypted by Bob's private key.

However, if Malory left Bob's portrait alone but replaced the modulus and exponent of the public key with his own, this would change the fingerprint, and rightly so: It would no longer be Bob's key, and encrypting something with it would give Malory access to it via Malory's private key.

We could build the fingerprint over all the elements of a public key, e.g. including all the signatures and additional personal information about the key owner, but if it worked like that, then every time you updated some trivial information in your key, or someone added another signature to it, your key fingerprint would change, and you'd have to explain to everyone that no, your key wasn't hacked, you just put in an new portrait image where your smile was more radiant.


How to verify a signature of one entity by another using OpenSSL CLI? I'm teaching a class about certificate chains, so I download the chain from www.google.com which has 4 certs.  I want to demonstrate how the dependencies work from issuer to subject by showing that each entity signs the cert of the one below it.

Call the certs g3, g2, g1 and g0 where g3 is a self-signed root, g2 and g1 are intermediate CAs and g0 is a leaf cert.  I try this:

$ openssl verify g0
error 20 at 0 depth lookup:unable to get local issuer certificate

This makes sense: the verify fails because this is a leaf cert with no CA given.  So next I try this:

$ openssl verify -CAfile g1 g0
g0: OK

Great!  With the intermediate, it now works!  Continuing up the chain:

$ openssl verify -CAfile g2 g1
g1: OK

Awesome!  Looks like g1 is properly signed by g2.  But this is actually not what's being verified.  Because g1 is also apparently signed by g3:

$ openssl verify -CAfile g3 g1
g1: OK

And in fact, g1 doesn't even need a CA:

$ openssl verify g1
OK

So it would appear that any cert with CA set to True in Basic Constraints will always pass verification!

Question: How do I verify that g2 actually signed g1 using OpenSSL from the CLI?  And is this yet another OpenSSL bug?  Or just counterintuitive behavior?

I believe certs g2 and g3 are already present in the default trusted directory (/etc/ssl/certs/) which openssl uses to build the chain of trust and find the 'trust anchor'.

In my setup:

  g2 = GeoTrust Global CA
    g3 = Equifax Secure Certificate Authority

Both of these certs are present in the /etc/ssl/certs/ directory.

If you try out the same experiment with a self-generated chain of certs, you will find the behaviour that you expect.


How session cookies work? I want to know the basic working of session cookies. When i tried googling, most of the results came were based on any programming language. I am not good at coding. So it will be helpful if someone can explain the working with the format of contents inside the cookie in simple English.

HTTP, the protocol used to communicate with webservers, without cookies is stateless -- it has no memory.  You make an HTTP request -- you tell your browser GET me the information from http://www.example.com/page01.html.  The webserver responds to your request and sends back the appropriate data, which your web browser then displays as appropriate.  If you then go visit a link to see page02.html, you start from scratch -- your browser asks the webserver GET the data from http://www.example.com/page02.html.  Yes, the webserver has your IP address, but if two people on your wifi network (same IP) both visit amazon.com, without cookies there would be no way to follow a unique user as they visit a variety of webpages in a weird order.

For interactive webpages where you can do actions on the web page, they need to keep track of the user to function.  E.g., if you go to a shopping website and want to add an item to your cart -- they need to keep track of who you are.  You wouldn't want some other user to suddenly see the items in your cart, or lose all the items in your cart every time you change the webpage by clicking a link.

Therefore, websites track users with a session cookie.  This is just a small text string -- typically 30 to 100 characters or so, that's randomly created for each user to be unique.  They store this identifier in a database, and attach information about each user in their database.  E.g., the user with the token e097e1136dc79bc1149e32a8a6bde5ef added 2 of item 38582 to the cart and 1 of item 57372 to their cart.

Then when you fetch a webpage from the dynamic website, you send the website your session cookie with your request -- GET http://www.example.com/dyanamic/page/ -- my cookie for example.com is e097e1136dc79bc1149e32a8a6bde5ef and then the webserver can look up your session cookie and recall all the information that is saved in the database about you so it can properly render the webpage you are supposed to see.

Note for a random 32 character session cookie with characters being 0-9 a-f, there are 2128 ~ 340 282 366 920 938 463 463 374 607 431 768 211 456 possible session cookies.  So even if a billion attackers tried a billion session cookies every second and did this for a billion years, they'd only be a 1 in 10000 chance they'd find your random session cookie.


Using a single application for user and admin (with different auth methods) vs separating them into two applications I am creating a human resource management application that allows access from both employee and HR administrator. Now, I'm faced with a best practice issue.

There would definitely be two users: Employee and HR Admin. I would just like to ask if it will be a security risk to put the HR admin side and the employee side together in one application and just provide different sets of pages for HR admin and employee (which will be determined by the account type of the logged in account). Is that considered best practice, or does it not pose security issues/threats? Or should I just create two separate applications (for employee side and HR admin side)?

Thanks!

Either option can work, if done correctly. In general, I would prefer to use the same application because it is simpler to maintain, particularly if the two applications share a lot of common code. However, there are some considerations which could tip the scales in favor of two distinct applications, mainly:

It is easier to lock down a separate HR application to more than simply a login role. For example, the Employee app may be publicly accessible via the internet, but the HR app could be locked down to the internal network, or even certain user's workstations.
It would be much harder to brute force a valid login for the HR app without having access to it.
With a single app, it is possible for a developer to make a mistake and accidentally expose admin functionality to regular users. This obviously would not happen with separate apps. (This is why I stressed "if done correctly" in the first sentence.)


A no-login approach to authenticating a certain device, MAC-Address as password? I have created a REST api, and now i'm thinking about authentication. I want the mobile application's flow for the user to be very simple: only having to enter a username and then this username together with 'some password' will be used to authenticate the user on every api call (using header fields, over SSL).

Is this a good way to authenticate the user with as little trouble for the user as possible? I believe whatsapp used a similar approach, using the device's MAC-address as the password, and let the user enter his phone number as username. I've also once read some critique on this approach, but if this is so bad, what is a better way of doing it?

So basically what i'm looking for is a way to do authentication with as little user input as possible (only a username), with at max one account per device, but for it to still be secure for calls to my api. Is there such an approach, if so, how would it go?

A MAC address is unsuitable for this for several reasons:

The MAC address can be changed freely by the user in software, and will change if the network hardware is replaced.
A wireless device broadcasts its address to everyone around, so it's hardly a secret.
MAC addresses are supposed to be unique, but in practice, they aren't.
A device with multiple network interfaces (say, a wireless card and an ethernet jack) will have multiple MAC addresses.

I'd look into something like client certificates, as mentioned by Dmitry Yanushkevich, or storing a unique token on the client as part of the account-creation process.


Finding spam sending scripts? What are the tips for finding email spam sending scripts? I ask because usually I hit a wall in shared hosting environments, so I ask this question as a way to get some insight from others.

What I do:

Check RBL's for the IP and possibly get the time the IP was listed.
Go through transfer.logs and FTP logs looking for any malicious activity.
Will watch transfer.logs in "live" mode (tail -fn0) watching for malicious activity.
grep for most recently modified script files (py,cgi,pl,php).
Run maldet / clamav; rarely finds any spam scripts though ;(
strace mail process if I have to.
Check if the UID of the sent script goes back to a user.
Check for X-PHP-Origin and X-Mailer email headers.
Utilize the findbot.pl script: http://cbl.abuseat.org/findbot.pl

Things we do on shared hosting platforms is limit/block outbound connections (especially UDP) and check for scripts trying to bind to ports (listeners). We force all SMTP traffic through our mailserver where we ratelimit SMTP traffic and store logs containing the customer's username. We assign unique user ID's per customer so we can track incidents to specific useres. We use FTP servers are checked on suspicious IP-addresses (from other continents mostly) and filenames being uploaded (known bad files for Joomla, Magento, etc). We have scripts detecting files being downloaded and uploaded with only a very limited time (seconds) between those actions, which turned out to be another good way of detecting compromised FTP accounts.

I haven't used it myself, but you might want to try HoneySpider (http://www.honeyspider.net/), which scans websites for malicious files, scripts, etc.


Sony Attacks, what would you do? If you where called by Sony right now, had 100% control over security, what would you do in the first 24-hours?

Typically, one has an approach that involves isolating breaches, identifying them, restoring service with the immediate attack vectors closed, and shoring up after that.

Sony's issue appears to be systemic. Their systems are varied, complicated, and numerous. As I understand it, weaknesses are everywhere. They cannot return to functioning because even they are not compromised in an isolated way.

In this way, Sony is a bad example for your idea. In another way, Sony is a fantastic boon to us. Need an example of poor security destroying something that didn't go out of business right away and wasn't too small to ignore? This is it.

Isolate and identify is now... forensics on the machines, work with law enforcement immediately because this is a "big fish" issue. Restoring service is just about out. Everything needs to be looked at from a basic level on up with security in mind. Sony in its present state may not even be able to identify where valuable data is located at.

You don't get here, because here is the bad place to be. Too big to react, too long without considering security implications. Nothing can be trusted, and fixing everything will be very expensive.


How can I use phpinfo.php file to find new files on a server I have been given a server to hack into for a cyber security class I have taken.

After using dirb to look at the file structure, the only accessible file was the phpinfo.php file. I need to use this file to find the path to other files.

However, I haven't been able to find any useful information yet.

The php version is 5.4.16. The file contains the system version, apache environment, mysql environment, http head information, PHP environment variables, and more.

What are some common exploits I could use with the phpinfo.php file? I'm trying to access more files on the server.

As stated in @Matthew's comment, the PHPinfo file itself does not pose a direct vulnerability, nor does it have "common exploits".

However, an exposed PHPinfo page is considered to be an information disclosure vulnerability, and may reveal significant information about other components or configurations which actually may be vulnerable.

As you have mentioned, the page displays version information for PHP, the system, Apache, MySQL; perhaps an online search for the product and version number will reveal some potential next steps (e.g. a search for "PHP 5.4.16 vulnerabilities"). Make sure to investigate the same for any installed modules as well.

If you aren't able to find any vulnerable and exposed software this way, perhaps an issue exists somewhere else on the page, maybe in the configuration of something, but it is impossible for us to know without being able to see the whole page. Identifying the vulnerability may require some background knowledge of the system and the services it is running.

Finally, it is possible that the PHPinfo page is just a small hint or perhaps a red herring, and it may be more fruitful to spend time taking a different approach. But again, it really depends on the situation, and there's no way to know for sure given the information in the question.


Should I trust a website which uses a SHA-1 HTTPS certificate? I am on a website where I need to pay for something. This website has the following warning in the top left:

  This site uses a weak security configuration (SHA-1 signatures) so
  your connection may not be private

Should I go ahead and enter my card details and pay for something on this site?

What are the security risks?

Extra Info:

I am using Google Chrome on a Windows 10 Machine.

In internet Explorer I get the following Message:

It's a bad sign, but it is still very unlikely that the connection is being eavesdropped on.

The website appears to have a valid certificate signed by a certificate authority, but it is signed with a weak and obsolete hash algorithm.

What does that mean?

It means the connection is encrypted and a passive eavesdropper can still not listen in. But a determined attacker with access to lots of processing power could generate a fake certificate for this website and use it to impersonate the website. So it is possible you aren't actually on the website you think you are but are instead on one controlled by a hacker. But such an attack would require quite a lot of resources and additionally require to be in control of a router between you and the website.

But even when we assume that no attack is taking place, we should keep in mind what impression this makes. SHA-1 is obsolete for quite a while now. When the admins of that site still do not bother to update, that's a quite bad sign for their general competence. It could mean that they are also quite lax regarding other aspects of security of their website. The final decision what information you provide them with is yours to make.


Does LUKS actually fully encrypt data on a disk? Why does TrueCrypt and similair applications take hours to fully encrypt a 1 tb drive, while luks takes a few seconds?

Sorry if this is a dumb question, but I don't fully understand how that works.

By default, luksFormat initializes the encrypted partition lazily, it only writes the LUKS headers and does not rewrite random data to the "empty space" of the encrypted partition when creating new partition. This means that you can create empty LUKS partition really quickly. Truecrypt by default initializes the entire partition with random data to the entire partition at creation time, for slightly better security.

  Does LUKS actually fully encrypt data on a disk?

Yes it does.


Is the CN field on an SSL cert a secure form of authentication? I'm using TLS client authentication for a machine-to-machine connection. In addition to ensuring the client has a valid cert, I'd like to have access control to ensure the request is originating from one specific entity.

Is checking the CN of a valid certificate a secure form of access control?

Example:

I want to only accept requests from example.com

Is checking that CN = example.com sufficient?

If the CN (or other parts of the certificate like SAN) is usable for authentication depends on how much you can trust the one who put the CN there to properly verify the value. For example with a self-signed certificates you cannot trust the CN at all since you cannot verify who created the certificate in the first place (anybody could) and thus cannot trust this one to properly validate the value in the CN.

With certificates issued for domains by a public CA it depends. If this is a cheap/free DV certificate the issuer if the certificate just checked that the owner of the certificate had at least for a short time partial control of the domain - either over the domains DNS, the domains web server or maybe the email (depending on the verification method). This could have been an attacker as recent events show again.
EV certificates on the other hand have more complex verification and thus are much harder to spoof.

Thus, if you can trust the one who puts the subject in the certificate to properly verify that the claimed owner is the actual owner and if you properly verify the certificate (issuer, expiration, revocation...) and if the sender of the certificate can prove ownership of the matching private key (done when used for authentication inside TLS) and if you can be sure that the private key is actually kept private by the owner (otherwise it is hopefully rejected) - then you can trust the value in the CN/SAN and use it for authentication.

And this is what is actually done in TLS: the server certificate is checked by the client to make sure that it talks to the right server (i.e. no man in the middle). Additionally a server might request a client certificate to authenticate the client. In protocols like SIP where each peer can be client and server it is not uncommon to have such mutual authentication (i.e. both server and client certificate) where the same certificate is used as server certificate when acting as server and as client certificate when acting as client.


Code signing certificate validation by Java Despite several web search, I can’t find an accurate explanation on code signing certificate validation by Java.

I am wondering if the code signing certificate (the “final cert”) must already be in the client Java truststore, or if the client only needs the Root CA (and its chain) in the Java truststore to validate it?

I can’t find Java docs that are really explicit about that, so I need technical details about the code signing certificate validation (where the certificate is fetch from, what is needed), not about the signing process.

If a jar is correctly signed, the verifier (often but not necessarily a network client) needs only the root, and if you use a public CA that root will usually already be there.

Specifically, a KeyStore privateKeyEntry is supposed to contain the full cert chain (although if the cert is self-signed the chain is only that one cert). When jarsigner signs using that privatekey (by alias) it creates a PKCS#7 SignedData detached signature, which includes the cert chain. For the case where the keystore can't provide the chain, jarsigner since Java7 has -certchain option to add them, see http://docs.oracle.com/javase/7/docs/technotes/tools/windows/jarsigner.html .

To verify a jar signature (or any signature containing a cert chain) Java actually can use any cert in the chain found in the local truststore. Since roots exist for the purpose of concentrating trust for all chains under them, it's conventional and easiest to have only roots in the local truststore. And JRE includes a default cacerts containing nearly 100 roots for "well-known" public CAs like Verisign and GoDaddy.

jarsigner -verify -verbose -certs [-keystore if_not_default] test.jar will show you the cert chain used, and mark the cert(s?) found in the truststore with its alias in parentheses at the right.


How to securely serve client-side-only web content to mobile with convenience? For a cryptocurrency client implementation, I am serving a single page webapp to mobile clients.  It is a client-side-only page.

I would like to serve this page to clients, but I fear tampering by hosts to change the code so that user passwords are intercepted.  The passwords, at least 128 bits of entropy enforced, are cryptocurrency signing key seeds.

Unfortunately, and this may be erroneous, it seems that mobile browsers cannot open and run local html files, or if they can, they cannot run css or js files.

I'm aware of apps that allow this, but I'd prefer that to be a last resort so to reach the least savvy.

Is the only option to physically manage a server myself to achieve the desired convenience?

Not understanding exactly what you are trying to defend against (see my comment above).

But in any way if you wish to serve html+css+js locally you could use Cordova to package your web app as a client app. Then you could also upload it to the market. (You can also use the OS's web browser controls to implement it yourself instead of using cordova)

Your other alternative is hosting your stuff on the web, probably utilizing PAAS as the preferred hosting option.


If my password was able to be printed on a form sent home from my child's school, does it imply insecure password storage policies? I have a user account for each of my children in our district website, which oversees registration, grades, identification, etc.

I was recently sent home a form from both of my children's classrooms asking us to login to our accounts so we could sign a new school year form. Printed on this piece of paper was both the username and the password for our accounts.

The security practice of sending home printed passwords is immediately discouraging, but my larger concern is how my password is stored in the district system (and ultimately, what would happen if that system were compromised).

I want to contact the webmaster, but I want to make sure I'm correct in any assumptions I make prior to shooting off my email asking that action be taken to avoid this kind of thing. I saw a related question, and want to make sure I don't jump the gun on harassing them over their storage policies.

--

Since it's been asked several times, this is a password that I set on the account, not an auto-generated password. Also, this is an account that parents control; it contains sensitive identifying information of your child. It's not intended as a student portal or anything like that.

--

Update_1 :

I got a call from the district webmaster today, wanting to discuss my email in more detail. I explained my concerns were two-fold: (a) the transmission of our password on a printed piece of paper, and (b) the ability to retrieve that password in the first place.

I was informed that the system is a legacy system, and as such has no capability of allowing a "forgot my password" feature. While the policy, they agreed, is incorrect, the alternative is to have every parent who doesn't remember their password come into the school with an ID to retrieve their password. (I was also informed that since we're in a 60% poverty district, assuming all parents have an email address for password management isn't an option). While this is and incredible inconvenient, I explained the inconvenience of likewise having someone access my accounts because they had access to my password.

I was also informed that the system is being replaced next year, which will come with more modern security features (though, I'm unsure of the storage policies on the future system).

The lady was very polite, and offered to put me in contact with their director of IT to discuss my concerns around password storage policies, which I accepted. She also offered to BCC me on an email to our school principal, requesting that future communications be issued in a sealed format.

Finally, I was slightly (and correctly) scolded for reusing my password in the first place.

Yup! If they are able to retrieve the password from the database, then they are clearly not following password storage best-practices. OWASP provides a good guide for how to do it properly:

https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet

Here's some ammunition you could use in that letter:

You want me (the legal guardian of my child) to sign a form.
You are using the action of logging into a website and clicking a button as a form of legal signature.
How do you know it was actually me that logged in and clicked the button?
How many people had access to the sheet with the username and password on its way to me? How can you prove that it was actually me that logged in and clicked the button?
Clearly the password is stored in the database in such a way that it can be retrieved by school board staff. How can you prove that it was actually me that logged in and clicked the button?
Were something to go wrong, I highly doubt that "signature" would hold up in court, meaning the form will not hold up in court. This seems like a liability issue for the school board and/or for me (depending on what's in the form).
Can I get a statement from the school board's legal team that this is ok?


Identify Malicious/Suscipicous Processes from Process List I have a list of 1000 processes and I want to identify which of them are legitimate and which are not. I only have the name of the processes and I want to categorize them. Is there any way to get information of those processes programmatically?

If I can at least identify which of them are common processes, that can help me to make a shorter list. I can then search other unknown processes and get their information.

Basically, I need to check a list of windows processes on a Mac/ Linux and I only have the names of the processes. I want to find the complete information of the processes so that I can find out the legitimate processes. There are current 1000 processes in the list and it may increase it in future. I can do it manually for now, but I want to run script to do the check automatically.

The list of common/legitimate processes will depend on the OS installed. Also, the list will depend on the software you have installed on your machine.

In Windows, you can trytasklistIn Linux, you can try ps

You can make a list of trusted applications(which you can do manually or lookup online). Then, after getting the list of running processes programmatically, you can compare the list with your trusted list of processes and display only the remaining processes.

If you feel that some these processes are harmless and legitimate, you can add these processes to your list of trusted applications, so that they won't show up again next time you run your program.


Checklist on building an Offline Root & Intermediate Certificate Authority (CA) Microsoft allows a CA to use Cryptography Next Generation (CNG) and advises of incompatibility issues for clients that do not support this suite.

Here is an image of the default cryptography settings for a 2008 R2 CA.  This machine is a non-domain connected Standalone CA:

Here are the installed providers.  The CNG providers are marked with a # sign

My intent is to have a general-purpose offline Root-CA and then several Intermediate CAs that serve a specific purpose (MSFT-only vs Unix vs SmartCards etc)

What are the ideal settings for a Root Certificate with an expiration of 5, 10, and 15 years?

CSP
Signing Certificate
Key Character Length

Since this is a RootCA, do any of the parameters affect low powered CPU (mobile devices)

Note: This is a (very very long) compendium of various recommendations and actions that Microsoft, NIST, and other well respected PKI and cryptography experts have said.  If you see something that requires even the slightest revision, do let me know.

Before I get into configuring the CA and its subs, it's good to know that even though MSFT's CryptoAPI requires a self-signed root, some non-MSFT software may follow RFC 3280 and allow any CA to be the trusted root for validation purposes.  One reason may be that the non-MSFT software prefers a lower key length.
Here are some configuration notes & guidance on setting up a CA ROOT and the Subs:
Storing the CA's Private Key

Best: Store the key on a HSM that supports key counting.  Every time the CA's private key is used, the counter will be increased.  This improves your audit profile.  Look for FIPS140 Level 3 or 4

Good: Store the Private key on a smart card. Though I'm unaware of any Smart Card that offers key counting, enabling key counting may give you unexpected results in the event log

Acceptable: Store the private key in Windows DPAPI.  Ensure that these keys and the Key Enrollment agent don't end up in Roaming Credentials.  See also: How to enumerate DPAPI and Roaming Credentials

Key Length

Don't use 1024 as a key length... NIST phased it out in 2011, MSFT won't ever add it into your Trusted Root CA store since it won't meet the minimum accepted technical criteria.

Root CAs that supports legacy apps should never be larger than 2048 bits.  Reason: MSFT Support sees many cases where Java apps or network devices only support key sizes of 2048 bytes.  Save the higher bit lengths to CAs that are constrained for a specific purpose (Windows vs Network devices) etc.

The NIST recommends 2048 or 3072 bits.  ECC is supported, though it may cause issues with device interoperability.

Plan for the strongest possible encryption (key length) throughout the PKI, otherwise expect mixed security benefits.

Mobile clients have issues (High CPU) or incompatibility with large keys

Expiration
The algorithm & Key length can have a bearing on how long you want certificates to be valid, because they effectively determine how long it might take an attacker crack, ie the stronger the cryptography, the longer you might be prepared to have certificates valid for
One approach is to establish what is the longest validity you'll require for end entity certificates, double it for the issuing ca's, and then double it again for root ca (in two tier). With this approach you would routinely renew each ca certificate when half of it's lifetime was reached - this is because a ca can't issue certificates with an expiry date after that of the ca certificate itself.
Suitable values can only really be determined by your organisation & security policy, but typically a root ca would have a certificate lifetime of 10 or 20 years.
If you're concerned about compatibility, set the expiration date below 2038.  This is due to systems that encode a data as seconds since January 1st 1970 over a signed 32 bit integer. Read more about this issue here.
Choosing a Hash

You may want to imitate the Federal PKI Management Authority and set up two PKI roots.  One modern SHA-256 for all devices that support it, and one legacy SHA-1.  Then use cross certificates to map between the two deployments.

Review this SHA-2 compatibility list for Microsoft software

Notably:

Windows 2003 and XP clients may need a patch for SHA2 Algorithms which include SHA256, SHA384, and SHA512. See more technical information

Authenticode and S/MIME with SHA2 hashing is not supported on XP or 2003

"Regarding SHA-224 support, SHA-224 offers less security than SHA-256 but takes the same amount of resources. Also SHA-224 is not generally used by protocols and applications. The NSA's Suite B standards also do not include it." source

"Do not use SHA2 suite anywhere in the CA hierarchy if you plan to have XP either trust the certificate, validate the certificate, use the certificate in chain validation, or receive a certificate from the CA. Even though XP SP3 allows validation of certiifcates that use SHA2 in the CA hierarchy, and KB 968730 allows limited enrollment of certificates that are signed by a CA using SHA2, any use of discrete signatures blocks out XP entirely." (source)

Choosing a Cryptographic Provider

View this list of providers for more information

Enable random serial number generation
As of 2012, this is required if you use MD5 as a hash.  It's still a good idea if SHA1 or greater is used.  Also see this Windows 2008R2 "how to" for more information.
Create a Certificate Practice Statement
A certificate practice statement is a statement of the practices that IT uses to manage the certificates that it issues. It describes how the certificate policy of the organization is interpreted in the context of the system architecture of the organization and its operating procedures. The IT department is responsible for preparing and maintaining the certificate practice statement. (source)
NOTE: In some situations, such as when digital signatures are used on binding contracts, the certificate practice statement can also be considered a legal statement about the level of security that is provided and the safeguards that are being used to establish and maintain the security level.
For assistance writing a CPS statement, here is a Microsoft produced "Job Aid"
Best Practice: Although it is possible to put freeform text into this field (see notice below), the ideal solution is to use a URL.  This allows the policy to be updated without reissuing the certificates, it also prevents unneeded bloating of the certificate store.
[LegalPolicy]
OID = 1.3.6.1.4.1.311.21.43
Notice = "Legal policy statement text"
URL = "http://www.example.microsoft.com/policy/isspolicy.asp"

Certificate Policies
Also known as issuance policies, or assurance policies (in MSFT), this is a self defined OID that describes the amount of trust one should put into your certificate (high, med, low, etc).  See this StackExchange answer for how to properly use this field.
Ensure Application Policies and EKU Policies match
Application Policies is an optional Microsoft convention.  If you are issuing certificates that include both application policy and EKU extensions, ensure that the two extensions contain identical object identifiers.
Enable CRL checking
Normally, a Windows Server 2003 CA will always check revocation on all certificates in the PKI hierarchy (except the root CA certificate) before issuing an end-entity certificate. To disable this feature, use the following command on the CA, and then restart the CA service:
 certutil –setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE

CRL Distribution Point
Special Guidance for Root CAs

This is optional in a Root CA, and if done incorrectly it may expose your private key.

All CRL publication is done manually from an offline RootCA to all other sub-CA's. An alternative is to use an audio cable to facilitate one-way communication from the Root to Sub CA's

It is perfectly acceptable to have the Root CA issue different CRL locations for each issued certificate to subordinate CAs.

Having a CRL at the root is a best practice if two PKIs trust each other and policy mapping is done.  This permits the certificate to be revoked.

Getting the CRL "right" is pretty important since it's up to each application to do the CRL check.  For example, smart card logon on domain controllers always enforce the revocation check and will reject a logon event if the revocation check cannot be performed or fails.

Note If any certificate in the chain cannot be validated or is found to be revoked, the entire chain takes on the status of that one certificate.

A self-signed root CA should not list any CDPs.  Most windows applications don't enable the CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT flag and therefore ignore the CDP (this is the default validation mode).  If the flag is enabled, and the CDP is blank for the self signed root cert, no error is returned.

Don't use HTTPS and LDAPS.  These URLs are no longer supported as distribution point references. Reason is that HTTPS and LDAPS URLs use certificates that may or may not be revoked. The revocation checking process can result in revocation loops when HTTPS or LDAPS URLs are used. To determine if the certificate is revoked, the CRL must be retrieved. However, the CRL cannot be retrieved unless the revocation status of the certificates used by HTTPS or LDAPS is determined.

Consider using HTTP instead of LDAP- Although AD DS enables publication of CRLs to all domain controllers in the forest, implement HTTP instead of LDAP for revocation information publication. Only HTTP enables the use of the ETag and Cache-Control: Max-age headers providing better support for proxies and more timely revocation information. In addition, HTTP provides better heterogeneous support as HTTP is supported by most Linux, UNIX, and network device clients.

Another reason to not use LDAP is because the revocation window to be smaller.  When using AD LDAP to replicate CA information, the revocation window couldn't be less than the time for all sites in AD to get the CA update.  Oftentimes this replication could take up to 8 hours... that is 8 hours until a smartcard user's access is revoked.  'Todo: the new recommended CRL refresh time is: ?????`

Make all the URLs highly available (aka don't include LDAP for external hosts).  Windows will slow down the validation process for up to 20 seconds and retry the failed connection repeatedly at least as frequently as every 30 min.   I suspect that Pre-fetching will cause this to occur even if the user isn't actively using the site.

Monitor the size of your CRL.  If the CRL object is so large that CryptoAPI is not able to download the object within the allotted maximum timeout threshold, a “revocation offline” error is returned and the object download is terminated.

Note: CRL distribution over HTTP with ETAG Support may cause issues with IE6 when using Windows 2003 / IIS6, where the TCP connection is continually reset.

(Optional) Enable Freshest CRL:  This non-critical extension lists the issuers and locations from which to retrieve the delta CRLs. If the “Freshest CRL” attribute is neither present in the CRL nor in the certificate, then the base CRL will be treated as a regular CRL, not as part of a base CRL/delta CRL pair.

The Microsoft CA does not put the “Freshest CRL” extension into issued certificates. However, it is possible to add the “Freshest CRL” extension to an issued certificate. You would have to write code to add it to the request, write a custom policy module, or use certutil –setextension on a pending request. For more information about advanced certificate enrollment, see the “Advanced Certificate Enrollment and Management” documentation on the Microsoft Web site

Warning If delta CRLs are enabled at a CA, both the base CRL and delta
CRL must be inspected to determine the certificate’s revocation
status. If one of the two, or both, are unavailable, the chaining
engine will report that revocation status cannot be determined, and an
application may reject the certificate.

CRL Sizing and maintenance (CRL Partitioning)
The CRL will grow 29 bytes for every certificate that is revoked. Accordingly, revoked certificates will be removed from the CRL when the certificate reaches its original expiration date.
Since renewing a CA cert causes a new/blank  CRL to be generated, Issuing CAs may consider renewing the CA with a new key every 100-125K certificates to maintain a reasonable CRL size. This issuance number is based on the assumption that approximately 10 percent of the issued certificates will be revoked prior to their natural expiration date. If the actual or planned revocation rate is higher or lower for your organization, adjust the key renewal strategy accordingly.  More info
Also consider partitioning the CRL more frequently if the expiration is more than 1 or two years, as the likelihood of revocation increases.
The drawback to this is increased startup times, as each cert is validated by the server.
CRL Security Precautions
If using a CRL, don't sign the CRL with MD5.  It's also a good idea to add randomization to the CRL signing key.
Authority Information Access
This field allows the Certificate validation subsystem to download additional certificates as needed if they are not resident on the local computer.

A self-signed root CA should not list any AIA locations (see reason here)

A maximum of five URLs are allowed in the AIA extension for every certificate in the certificate chain. In addition, a maximum of 10 URLs for the entire certificate chain is also supported. This limitation on the number of URLs was added to mitigate the potential use of “Authority Info Access” references in denial of service attacks.

Don't use HTTPS and LDAPS.  These URLs are no longer supported as distribution point references. Reason is that HTTPS and LDAPS URLs use certificates that may or may not be revoked. The revocation checking process can result in revocation loops when HTTPS or LDAPS URLs are used. To determine if the certificate is revoked, the CRL must be retrieved. However, the CRL cannot be retrieved unless the revocation status of the certificates used by HTTPS or LDAPS is determined.

Enable OCSP Validation
The OCSP responder is conventionally located at: http://<fqdn of the ocsp responder>/ocsp.  This url needs to enabled in the AIA.  See these instructions for Windows.
Do know that full OCSP validation is off by default (though it should be "on" for EV certs according to the specification).  In addition, enabling OCSP checking does add latency to the initial connection
More secure systems will want to enable OCSP monitoring on the client or the server side
OCSP Cache duration
All OCSP actions occur over the HTTP protocol and therefore are subject to typical HTTP proxy cache rules.
Specifically the Max-age header defines the maximum time that a proxy server or client will cache a CRL or OCSP response before using a conditional GET to determine whether the object has changed.  Use this information to configure the web server to set the appropriate headers.  Look elsewhere on this page for AD-IIS specific commands for this.
Define a policy in issued certificates
The parent CA defines whether or not to allow CA certificate policies from sub CAs.  It is possible to define this setting when a issuer or application policy needs to be included in a sub CA.
Example polices include an EKU for SmartCards, Authentication, or SSL/Server authentication.

Beware of certificates without the Certificate Policies extension as it can complicate the Policy Tree.  See RFC 5280 for more information

Know that policy mappings can replace other policies in the path

There is a special policy called anypolicy that alters processing

There are extensions that alter anypolicy

If you use certificate policies, be sure to mark them as critical otherwise the computed valid_policy_tree becomes empty, turning the policy into a glorified comment.

Monitor the DN length enforcement
The original CCITT spec for the OU field says it should be limited to 64 characters. Normally, the CA enforces x.500 name length standards on the subject extension of certificates for all requests. It is possible that deep OU paths may exceed normal length restrictions.
Cross Certificate Distribution Points
This feature assists where environments need to have two PKIs installed, one for legacy hardware/software that doesn't support modern cryptography, and another PKI for more modern purposes.
Restrict the EKU
In contrast with RFC 5280 that states “in general, [sic] the EKU extension will appear only in end entity certificates." it's a good idea to put constraints on the CA Key usage.
A typical stand-alone CA certificate will contain permissions to create Digital Signatures, Certificate Signing, and CRL signing as key values.  This is part of the issue with the FLAME security issue.
The MSFT smart card implementation requires either of the following EKUs and possibly a hotfix

Microsoft smart card EKU
Public Key Cryptography for the Initial Authentication (PKINIT) client Authentication EKU, as defined in the PKINIT RFC 4556

It also has interesting constraints around validating EKU (link tbd).
If you're interested in having any EKU restrictions you should see this answer regarding OIDs and this regarding contrained certificates
Use caution with Basic Constraints "Path"
The Basic Constraint should describe if the certificate is an "end entity" or not. Adding a path constraint to a intermediate CA may not work as expected since it's an uncommon configuration and clients may not honor it.
Qualified Subordination for Intermediate CAs

To limit the types of certificates a subCA can offer see this link, and this one

If qualified subordination is done, revoking a cross signed root may be difficult since the roots don't update the CRLs frequently.

Authority Key Identifier / Subject Key Identifier
Note If a certificate’s AKI extension contains a KeyID, CryptoAPI requires the issuer certificate to contain a matching SKI. This differs from RFC 3280 where SKI and AKI matching is optional.  (todo: Why would someone choose to implement this?)

Give the Root and CA a meaningful name
People will interact with your certificate when importing it, reviewing imported certificates, and troubleshooting.  MSFT's recommended practice and requirement is that the root has a meaningful name that identifies your organisation and not something abstract and common like CA1.
This next part applies to names of Intermediate/subCA's that will be constrained for a particular purpose: Authentication vs Signing vs Encryption
Surprisingly, End users and technicians who don't understand PKI's nuances will interact with the server names you choose more often than you think if you use S/MIME or digital signatures (etc).
I personally think it's a good idea to rename the issuing certificates to something more user friendly such as "Company Signer 1" where I can tell at a glance

Who is the signature going to come from (Texas A&M or their rival)
What is it used for? Encryption vs Signing

It's important to tell the difference between a message that was encrypted between two parties, and one that was signed.  One example where this is important is if I can get the recipient to echo a statement I send to them.  User A could tell user B "A, I owe you $100".  If B responded with an echo of that message with the wrong key, then they effectively digitally notarized (vs just encrypting) a fictitious $100 debt.

Here is a sample user dialog for S/MIME.  Expect similar UIs for Brower based certificates.  Notice how the Issuer name isn't user friendly.

Alternate Encodings
Note: Speaking of names, if any link in the chain uses an alternate encoding, then clients may not be able to verify the issuer field to the subject.  Windows does not normalize these strings during a comparison so make sure the names of the CA are identical from a binary perspective (as opposed to the RFC recommendation).

High Security/Suite B Deployments

Here is information regarding the Suite B algorithms supported in Windows 2008 and R2
ALGORITHM                                          SECRET           TOP SECRET
Encryption:
Advanced Standard (AES)                            128 bits         256 bits
Digital Signature:
Elliptic Curve Digital Signature Algorithm (ECDSA) 256 bit curve.   384 bit curve
Key Exchange:
Elliptic Curve Diffie-Hellman (ECDH)               256 bit curve.   384 bit curve
Hashing:
Secure Hash Algorithm (SHA)                        SHA-256           SHA-384

For Suite B compliance, the ECDSA_P384#Microsoft Software Key Service Provider as well as the 384 key size and SHA384 as the hash algorithm may also be selected if the level of classification desired is Top Secret.  The settings that correspond with the required level of classification should be used. ECDSA_P521 is also available as an option.  While the use of a 521 bit ECC curve may exceed the cryptographic requirements of Suite B, due to the non-standard key size, 521 is not part of the official Suite B specification.

PKCS#1 v2.1

XP clients and many non-windows systems do not support this new signature format.  This should be disabled if older clients need to be supported. More Info

I would only recommend using it once you move to ECC algorithms for asymmetric encryption. (source)

Protect Microsoft CA DCOM ports
The Windows Server 2003 CA does not enforce encryption on the ICertRequest or ICertAdmin DCOM interfaces by default. Normally, this setting is not required except in special operational scenarios and should not be enabled. Only Windows Server 2003 machines by default support DCOM encryption on these interfaces. For example, Windows XP clients will not by default enforce encryption on certificate request to a Windows Server 2003 CA. source
CNG private key storage vs CSP storage
If you enroll Certificate Template v3, the private key goes into the CNG private key storage on the client computer. If you enroll Certificate Template v2 or v1, the private key goes into CSP storage.   The certificates will be visible to all applications in both cases, but not their private keys - so most applications will show the certificate as available, but will not be able to sign or decrypt data with the associated private key unless they support CNG storage.
You cannot distinguish between CNG and CSP storages by using the Certificate MMC. If you want to see what storage a particular certificate is using, you must use CERTUTIL -repairstore my * (or CERTUTIL -user -repairstore my *) and take a look at the Provider field. If it is saying "... Key Storage Provider", than it is CNG while all other providers are CSP.
If you create the initial certificate request manually (Create Custom Request in MMC), you can select between "CNG Storage" and "Legacy Key" where legacy means CSP.
The following is my experience-based list of what does not support CNG - you cannot find an authoritative list anywhere, so this arrises from my investigations over time:

EFS
Not supported in Windows 2008/Vista, Supported in Windows 7/2008R2

user encryption certificates

VPN/WiFi Client (EAPTLS, PEAP Client)

Windows 2008/7
Not supported with user or computer certificate authentication

TMG 2010
server certificates on web listeners

Outlook 2003
user email certificates for signatures or encryption

Kerberos
Windows 2008/Vista- DC certificates

System Center Operations Manager 2007 R2

System Center Configuration Manager 2007 R2

SQL Server 2008 R2-

Forefront Identity Manager 2010 Certificate Management

More information on CNG compatibility is listed here (in Czech, though Chrome handles the auto-translation well)
Smart Cards & Issuing CAs
If you plan on giving users a second smart card for authentication, use a second issuer CA for that. Reason: Windows 7 requirements
Use the Windows command CERTUTIL -viewstore -enterprise NTAuth for troubleshooting Smartcard logins.  The local NTAuth store is the result of the last Group Policy download from the Active Directory NTAuth store. It is the store used by smart card logon, so viewing this store can be useful when troubleshooting smart card logon failures.
Decommissioning a PKI Tree
If you deploy two PKI trees, with the intent to decommission the legacy tree at some point (where all old devices have become obsolete or upgraded) it may be a good idea to set the CRL Next Update field to Null.  This will (should?) prevent the continual polling for new CRLS to the clients.  The reasoning is that once the PKI is decommissioned, there will be no more administration, and no more revoked certs.  All remaining certs are simply left to expire.
More information on PKI decommissioning available here


Which Domain Administrator created file X on a Windows 2008 R2-based server? Someone created a file (web.config) in a location that basically caused IIS to not work.  Is there any way I can determine who created this file?

The creator/owner says "Domain Administrators".

This is a Windows 2008 R2 server.

There's not a direct way to find out who exactly created the file on NTFS by hindsight. However, you might have a chance checking the event logs to determine who was logged in as an admin by that time. If you're lucky there was only one administrator present.

If you want to monitor such activities for certain directories from now on, there're various tools available. It can be done with process monitor for example, and if it's not a local account that is creating those files you can perform a lookup with netstat on the PID to get the IP of the user.


Why don't wifi managers remember mac addresses for hotspots to defeat the jasager attack? So I just learned about the jasager attack, via the wifi pineapple and it struck me immediately that it wouldn't work at all if network managers (privately) associated MAC addresses with hotspots and asked for explicit permission if you were going to connect to a new physical device.

Obviously this would be mildly irritating in public hotspots where devices change and hundreds of diverse locations share network names, but it would make home and work networks much harder to penetrate.

I haven't found any wifi managers that do this, or at least I haven't found information that any do.

My question:

Am I missing something obvious? Would remembering MACs not actually increase security?
If it would, are there any network managers that do this? (I'm on Linux, but if there are tools for other OS's I think it's worth having them in the answers)

You didn't provide a good description of the attack you are concerned, but I believe you're referring to the following attack: a malicious "evil twin" access point can pretend to be a legitimate access point and fool your device into connecting to it; then it can play man-in-the-middle.

If this is what you had in mind, then remembering MAC addresses would not prevent this attack.  Spoofing the MAC address is trivial because they must be transmitted over-the-air: on an unencrypted system everyone nearby can see it.

If a system is WPA-secured MAC filtering doesn't add to the security.


Is there any security benefit of not using email services recently associated with PRISM? After the recent disclosure of several major email providers cooperating with NSA, is there any real security benefit of not using these email services and choose some alternative instead? Such as picking a local email provider or hosting an email server myself?

All emails are publicly visible as they pass through routers, and I suppose security agencies are monitoring all Internet backbones anyway.

More recent leaks and evidence suggests that the email providers themselves are, as a rule, not cooperating with the NSA. Rather the telecom companies such as AT&T are. The NSA wholesale captures and analyzes all the traffic upstream of companies like Google and Yahoo, and through that get implicit access to anything that isn't encrypted. So the critical detail is this: Which companies encrypt their traffic?

I did some tests, and here's what I came up with:

Email Encryption Availability

Forced:         +++
On by default:  ++
Off by default: +
Not available:  -
Outbound Only:  +*

                  Gmail     Microsoft   Yahoo      AOL
Web Interface     +++       +++         +          -
POP3/IMAP         +++       +++         ++         ++
SMTP              ++        -           +*         +*

So Gmail does encryption everywhere it's possible, and won't even let you connect unencrypted if you're fetching your email.

Microsoft (Live/Hotmail/Outlook.com, etc.) Forces you to encrypt to retrieve your mail, but does not support STARTTLS on port 25, neither inbound or outbound, so all mail to and from them is unencrypted.

Yahoo supports SSL across the board, but it's off by default on the web interface.

AOL doesn't even support SSL on their web interface, but does support it on the backend.

There's no "default" on/off state for SSL on POP3/IMAP, so I gave everyone the benefit of the doubt there.

Possibly most interesting: GMail will encrypt everything if you allow it, including server-to-server. Microsoft will not encrypt server-to-server, while Yahoo and AOL both do something odd: Both will encrypt server-to-server outbound email, but do not support STARTTLS on inbound email. So mail going from Yahoo or AOL will be encrypted if the destination supports it (e.g. Gmail), but mail going to Yahoo or AOL cannot be encrypted.

But with respect to server-to-server encryption, there's a catch: unencrypted connections are always supported, which makes a man-in-the-middle attack trivial. Simply MITM the connection on PORT 25, and filter out the line where the destination server advertises STARTTLS availability. Also, since certificate validity is rarely checked by mail servers, you can MITM the TLS session as well with a self-signed certificate.

Caveat Emailor
Remember that email is inherently insecure in its very design. Using your ISP's email service or setting up your own may not be any better. Remember that its the network backbones that are getting tapped, not the mail service providers. So we're all similarly vulnerable. Use S/MIME or PGP/GPG if you need email security.


What's the best practice when using a VPN and a VM I am currently on a virtual machine connected to the network via NAT. I wondered what's the best practice when I want to connect to a VPN.

Should I connect to the VPN from my host OS or from my guest OS ? My guess is that if I connect from the host OS, my host OS and my VM will be protected by the VPN and if I connect from the guest OS, only the VM will be protected. Am I right ?

Cheers,

Depends why you are connecting to the VPN, and the configuration of it.

Connecting to a VPN to access data on a different network: if you only need to access the data from within your VM, connect from your VM, else connect from the guest OS - minimal exposure.
Connecting to a VPN to hide network traffic from the network owner: Connect from the guest OS - all traffic encrypted.

In the first case, other traffic may or may not go through the VPN - this is the configuration part.

In either case, a VPN only protects against a limited range of threats: specifically those which result from network traffic being monitored. You'd still be vulnerable to malware, poorly coded websites, and people looking over your shoulder!


How to prevent someone guessing the token in a reset password link Currently I have the following set-up for handling users that forgot their password.

A user types in his/her e-mail address and presses the forgot password button.
I look up the user belonging to that e-mail address and I store a new 'forgot password request' in the database. The forgot password request item looks like this:

Guid ForgotPasswordRequestId;
Guid UserId;
DateTime ValidUntil;

I generate a token to identify the forgot password request by converting the ForgotPasswordRequest Guid to a Base64 string. The Guid is a version 4 Guid (random, not time or MAC address based). Check this MSDN link for notes on the implementation.
I create a link like www.example.com/account/ForgotPassword?token=TOKEN which is sent to the user in an e-mail.
Whenever someone visits that link within 24 hours he/she can set a new password for that account.

I think the chances of someone guessing the token is small as a Guid is a 122 bit number (128 bits, minus 6 bits for version information). So a hacker would need to try, on average, (2^122 / 2) tokens within 24 hours before succeeding. If my math is correct that is 3 * 10^31 tokens per second, which I'm sure my server can't handle ;).  Also the token they need to guess is in no way related to the user they wish to reset the password for.

However, is it correct to generate the token directly from a generated Guid? Is there anyway that using a Guid and not a secure random number generator makes an attack feasible? Is there any other problem in this scheme that makes it unsecure?

I've seen this question, although its related it doesn't explain best practices for generating the token.

You should create a cryptographically random token for this. Yours is definitely not random enough, and could be guessed much quicker than the (2^122 / 2) you mention. The importance of cryptographic randomness has been discussed many times already on this forum, for example here.

As you mention that you are using .net, have a look at ASP.Identity which can generate tokens for you, using the DataProtectorTokenProvider. If you are not using ASP.Identity (or Owin for that matter), you can also look into using RNGCryptoServiceProvider to generate secure random tokens.  I'm not saying you could not do it yourself, but it is hard.

Edit: If you are talking about a GUID (as you reference to it), you can read this answer:

  To identify a user of an online banking application on the other hand, (or really probably even a password reset function of a site where identity is valuable) GUIDs are definitely inadequate.


How to know if my router has been hacked? I have a (maybe dumb) question for you. I was wondering if there is a way to know if my router has been hacked.

I secured it the best that I can and also made it so only the mac addresses of the devices that I know can access my WiFi.

I turned off uspn, WPS, and remote access to the router settings even though I noticed that the page won't load anymore on the device I used to set it up but it loads on my phone.

While days ago it would not load on my phone but it would on other devices but I keep seeing accesses to my social medias by devices that seem to be mine but I nor everyone else in my family used lately.

I'm afraid someone hacked my router and is using my devices remotely. How can I be sure? Would calling my ISP help? My router is from my ISP.

There is a good chance that your router itself has not been hacked. By default, ISP routers usually heavily restrict inbound connections from the Internet.

  but I keep seeing accesses to my social medias by devices who seem to be mine but I
  nor everyone else in my family used lately

All social medias? What kind of access are you seeing?

My advice would be to change your social media passwords immediately and wait to see if the mysterious accesses stop.


What determines the type of HTTPS indicator shown by Chrome? I noticed recently that Chrome 55 shows different HTTPS indicators - sometimes it shows " Secure", sometimes it indicates the company name (which, to my understanding, is associated with the HTTPS certificate) - and I was hoping someone could shed some light on why this is the case.

Examples below:

Many web browsers now will differentiate the "padlock" placed beside a web address when the website uses different types of SSL/TLS certificates. These certificates are used to generate a secure session in which data is encrypted between your browser and the destination web server.

The example you have provided is a difference between eV (extended Validation) and "regular" certificates.

In the case of eV certificates, there is a much more rigorous, and in depth procedure when obtaining such a certificate. Company information and owner information are examples of details required in a eV certificate. It allows visitors to identify the website, and verify the company who holds the certificate, is in fact the one running the website. Owner information and such are not required when requesting a "normal" SSL/TLS certificate.

Firefox makes a bigger differentiation for eV certificates, where a simple green padlock is replaced with a wider green bar containing the company's name and country abbreviation (US/CAN/UK).


Migrate a x509 key using KSP (CNG) to CSP (CryptoAPI) in Windows I have a code signing certificate issued to me by a commercial CA, and the key was generated on my local development machine using the new Cryptography Next Generation storage providers.

Unfortunately, the Visual Studio ClickOnce manifest code signing tool only supports the older CSP/CrytoAPI keys for signing these manifests (the error I get is: "An error occurred while signing: Invalid provider type specified.").

I have the certificate currently as a .PFX file on my computer.  When I use certutil to view the details of the certificate, it shows these details:

Provider = Microsoft Software Key Storage Provider
ProviderType = 0

How can I change my private key/certificate from using CNG to using the older style CrytoAPI? I don't want to buy another certificate if at all possible.

It can be done using openssl. The procedure is as follows:

convert the source PFX to PEM
convert the PEM back to PFX

Example:

openssl pkcs12 -in mycert-cng.pfx -out mycert.pem
openssl pkcs12 -export -in mycert.pem -out mycert-cryptoapi.pfx

On my machine (Windows 8.1, openssl 0.9.8zf), the resulting pfx referenced the "Microsoft Enhanced Cryptographic Provider v1.0" CSP. openssl pkcs12 also provides an option to request a specific CSP (-CSP "CSP name").

Windows binaries of openssl can be downloaded e.g. from here.


Data protection laws and regulation for storing IP addresses for registered users I have a website, large amounts of this site can only be accessed if the user logs in. I would like to use the users IP addresses as a means to determine where they are when they access certain pages.

I would like to use the users IP to determine if they are at a certain institute (company, university, school etc.). I know the IP address ranges for the institute (e.g. 0.0.1.0 to 0.0.1.255) and I know the users IP address e.g. 0.0.1.1.

Ideally I would store the users IP address in a database which would enable me to say "Person X accessed page Y from computer 0.0.1.1".

I have read, on various forums, that there are some things you need to be careful of when storing IP addresses which can be linked to specific users. In some cases people say they must be deleted after 90 days, I would like to avoid deleting this information until the user is no longer registered with my site.

Can I store this information without breaching any laws or data protection acts etc?

To summarise:

I would like to store IP addresses for known users every time they access certain pages
I would never store IP addresses for visitors who are not registered with my site
The information would be stored until the user is no longer registered with the site (at which point the IPs will be deleted).
I'm sure laws vary from country to country so for clarity: all registered users are in the UK (the data is also stored in the UK)

You should definitely check both European and UK Data protection laws to be sure, but as long as you don't collect and store Personally Identifiable Information (PII), you won't have to really bother with laws and regulations.

More precisely:

  An IP address in isolation is not personal data under the UK Data
  Protection Act, according to the Information Commissioner. But an IP
  address can become personal data when combined with other information
  or when used to build a profile of an individual, even if that
  individual's name is unknown.

So this has to be determined based on the type of information you collect and/or store from your users.

Also, as mentionned into comments this does not seems like the right approach to achieve this.


Can a Linux environment be PCI compliant if the swap file is not encrypted and PANs are loaded into RAM? Can a Linux environment be PCI compliant if the swap partition/file is not encrypted and PANs are loaded into RAM by an application?

PCI compliance covers a lot of ground - anything that "stores", "processes" or "transmits" cardholder data.

Different systems need to have different parts of the standard applied to them to maintain a cohesive whole. Your system would fall into the "processes" category. Your needs would be different for storage, etc.

In the case you have outlined you can accomplish the protection of cardholder data written to disk in two distinct fashions. Either locking the pages holding cardholder data in RAM,  encrypting the swap file, or both.

A third less desirable option is totally disabling the swap file.

As true as all this is you seem to be missing the big picture - PCI compliance doesn't come from just keeping the credit card information in RAM.

There are a lot of other things that you need to consider, even if you are only handling cardholder data in RAM. Central logging, HIDS, NIDS, etc.


How to detect when one or more devices in my local network have become DDOS attack nodes? I have a home network, big family, with around 20 devices on it at any given time. It seems like every year or so, some device gets a virus or a security flaw is revealed, and the device starts behaving badly.

Normally the device will behave badly and try to password crack my network folders etc.

But the latest thing we have experienced this year is that the affected device will start firing off 1000's of requests to some site. Afterwards, I get on a DDOS ban list. For example, I can at this time not access

https://www.usps.com/
http://io.playstation.com/
https://www.angieslist.com/
https://aa.com/
... and more.

An answer below has helped me understand that this is due to Akamai Tecnhologies blocking my IP. I called Akamai Tecnhologies and they confirmed this and let me know that my IP was suspected as "Web Scraping." Meaning some sort of malware must have made tons of web requests to site(s) protected by Akamai Tecnhologies and therefore got flagged as a DDoS attacker. Not necessarily malware, it could have been some rogue software issue that caused these excessive requests too. I have contacted them trying to get the exact sites it hit so that I can debug further.

This sucks because my ISP does not allow me to change my IP address so I'm stuck banned.

I have my router's QoS feature turned on and I do not see any suspicious network behavior at this time. But that could change at any given moment.

So now the question:

What methods are there to identify this situation so that I can take immediate action?

Namely, I need a way to get an alert when my home network has suddenly become a DDOS attack node. Ideally something could be attached to the router to send me a notification - "hey device IP 192.168.1.x just started making 1000's of requests to sites so I have blocked its access until you take action."

So far this is what I have done:

See How do I know if my computer is being used for a botnet-based DDoS attack?
Changed all passwords, set up 2factor authentication on all password manager sites, etc.
Formatted all the windows laptops with fresh copies of windows, because Windows has a higher tendency to have viruses.
Virus scanned my whole network.
Block all TCP/UDP traffic to any devices that are meant to be used in local intranet only. Such as my security cameras and android tablets that monitor those cameras.
Anti-virus software on each device, make sure software updates are kept up to date, etc.
Make sure no one but me has admin access of devices. All user accounts on each computer are restricted to just what that person needs.

UPDATE:

I'm using a netgear R9000 router. Do you think there are any REST/SOAP api web services that I can use to create a simple program that watches for DDoS attack patterns?

Set up a Pihole to block ads, malicious sites and to log DNS requests. When the numbers spike you'll know where to block and who is causing the issue.

As explained in the pi-hole documentation (and video documentation) you configure your router to use the pi-hole machine as a DNS server. See this video circa 0:57 seconds: youtube.com/watch?v=vKWjx1AQYgs

Any Linux box will do, not necessarily a Raspberry Pi. I added block lists for Microsoft Telemetry and Spybot immunization list.

https://pi-hole.net


Should I be concerned that Google no longer trusts specific Symantec root CA cert that is also on my Windows system? This is related to this other question which refers to Google moving to distrust the "Class 3 Public Primary CA" root certificate operated by Symantec Corporation, across Chrome, Android, and Google products, as explained in this Google blog post.

Google's blog post said that Google will be making this change "over the course of the coming weeks".

Google mentions among the reasons for their request that:

  Symantec has informed us they intend to use this root certificate for purposes other than publicly-trusted certificates.

and

  Symantec is unwilling to specify the new purposes for these certificates

The blog post provides the details for this certificate as being:

Friendly Name: Class 3 Public Primary Certification Authority
Subject: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority
...
MD2 Version
Fingerprint (SHA-1): 74:2C:31:92:E6:07:E4:24:EB:45:49:54:2B:E1:BB:C5:3E:61:74:E2

So I checked the Trusted Root CAs on my Windows 7 Pro (using certmgr.msc) and the the Friendly Name and Subject matches the details of a Trusted Root CA on my system. Additionally the SHA-1 Fingerprint posted by Google matches the Thumbprint in the CA on my system.

My questions are the following:

Does Google's decision mean that it would be prudent for me to also delete or disable the root CA from my machine?
Or might Microsoft Windows have some automated process that would also stop trusting the same certificate (in for example IE)?
Also, instead of deleting the root CA, I could go to it's properties and maybe update it with "Disable all purposes for this certificate". Would there be any benefits from choosing this option instead?

Does Google's decision mean that it would be prudent for me to also delete or disable the root CA from my machine?

Dunno. Symantec ain't being too helpful. Theoretically it should not hurt but something seems to be broken in clients.
Also: Vendors don't seem to agree on this.
I've whipped up a quick script and parsed four trust stores (Apple, Java, Microsoft, Mozilla) that the ssylze SSL test tool ships with:
$ grep -rl 'Issuer: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority$' | xargs -- grep -A2 -- 'Serial Number'
apple.truststore/108.cer.txt:        Serial Number:
apple.truststore/108.cer.txt-            70:ba:e4:1d:10:d9:29:34:b6:38:ca:7b:03:cc:ba:bf
apple.truststore/108.cer.txt-    Signature Algorithm: md2WithRSAEncryption
--
apple.truststore/164.cer.txt:        Serial Number:
apple.truststore/164.cer.txt-            3c:91:31:cb:1f:f6:d0:1b:0e:9a:b8:d0:44:bf:12:be
apple.truststore/164.cer.txt-    Signature Algorithm: sha1WithRSAEncryption
--
java.truststore/143.cer.txt:        Serial Number:
java.truststore/143.cer.txt-            3c:91:31:cb:1f:f6:d0:1b:0e:9a:b8:d0:44:bf:12:be
java.truststore/143.cer.txt-    Signature Algorithm: sha1WithRSAEncryption
--
java.truststore/61.cer.txt:        Serial Number:
java.truststore/61.cer.txt-            70:ba:e4:1d:10:d9:29:34:b6:38:ca:7b:03:cc:ba:bf
java.truststore/61.cer.txt-    Signature Algorithm: md2WithRSAEncryption
--
microsoft.truststore/15.cer.txt:        Serial Number:
microsoft.truststore/15.cer.txt-            70:ba:e4:1d:10:d9:29:34:b6:38:ca:7b:03:cc:ba:bf
microsoft.truststore/15.cer.txt-    Signature Algorithm: md2WithRSAEncryption

So: (if the sslyze stores are up to date) Apple has both, Java has both, Microsoft has one. Mozilla has none.
Sidenote: sslyze also ships with a "Google" trust store, I've skipped that, because I don't know what that even is. (For Android phones maybe?) For one thing, Chrome does not use its own trust store. It relies on the OS trust store. And this may be the root of the problem here. They can't just remove a CA, they must explicitly revoke it. -- Mozilla Firefox has it easier in that respect, since they run their own trust store.

Or might Microsoft Windows have some automated process that would also stop trusting the same certificate (in for example IE)?

Yes. They have an automated CA update mechanism. And they regularly make changes. For example they announced the intention to remove some 20 CAs just today.

Also, instead of deleting the root CA, I could go to it's properties and maybe update it with "Disable all purposes for this certificate". Would there be any benefits from choosing this option instead?

Absolutely. Either that or moving the certificate to the Untrusted Certificates store. Otherwise it will just be re-added by the automated process.
Update 2015-12-30Wed. Oh dear, oh dear, oh dear.
Ryan Sleevi made another blog post. This time privately and not as a Google spokesperson and has these (discouraging) words to say about it:

Ryan Sleevi, blogged via Medium.com, A History of Hard Choices:

December 2015: With only one week’s notice, Symantec requests that a root certificate trusted on billions of devices be revoked, so that Symantec will no longer be obligated to abide by the Baseline Requirements for that root. Without this notice, Symantec’s use of their root in this manner would have been in violation of their agreements with root programs, putting at risk every other root certificate they operate and every single customer of theirs. Yet, even with this notice, it will likely take years to reduce the number of users and devices at risk from certificates issued by Symantec from this root to a something quantified in the tens of millions.

Steps to explode apple.pem bundle
I ran these commands to split the PEM bundle into individual PEM files:
[~] $ wc apple.pem
  4903   5279 303714 apple.pem
[~] $ mkdir apple.truststore
[~] $ cd apple.truststore/
[~/apple.truststore] $ awk 'split_after==1{++n;split_after=0} /-----END CERTIFICATE-----/ {split_after=1} {print > "cert" n ".cer"}' < ../apple.pem
[~/apple.truststore] $ for RAWCERTFILE in *.cer; do openssl x509 -in $RAWCERTFILE -text 2>&1 > $RAWCERTFILE.txt; done


Hiding or Obscuring Data from ISPs With the recent vote by the US Congress to relax internet privacy regulations(see here), I'm wondering if there is anything I can do to prevent data gathering by my ISP. From the article I linked, there were rules preventing ISPs from gathering and sharing

  "'precise geo-location, financial information, health information, children’s information, social security numbers, web browsing history, app usage history and the content of communications' ...[and] less sensitive information, like an email address."

Since all of my traffic dealing with sensitive info, e.g. health info, SSNs, etc., is done over HTTPS, I don't think they would be able to see that data. I'm aware of the possibility of them guessing content from side-channel information, but what I've read has made it seem like protecting against that is not currently feasible. So, ideally, I'd like to be able to prevent them from gathering browsing history, DNS request, geo-location, and communication data.

My initial thought was that it wasn't possible, but I would love to be wrong.

As you have given a list of information you would like to protect from your ISP, I will try to give you some hints:

browsing history:

Your browser is normally not provided by your ISP, so if you consistently apply security patches, it should not be able to access it from your browser - I would not be as sure as what Chrome reveals to Google. But all your network traffic passes through its routers so they can log every plain HTTP request, and at least the IP destination and size of your HTTPS request and their responses.

=> if you want to hide the HTTPS sites that your browse, you should considere using a VPN or TOR: the ISP will only know that you use a VPN. This part is IMHO fully relevant regarding the new US congress vote. Simply you have to trust the VPN owner to not collect and sell back your data... (read: do not trust a free VPN to respect your privacy)
DNS requests:

you normally use the DNS from your provider so they can log all of them. Even if you try to use a third party DNS server (but anyway that one will log your requests) the DNS request will pass in clear text through the ISP router, so it can also log them.

=> You could try to connect to  a third party DNS server through IPSEC - and trust the DNS owner to not collect your data... Alternatively or in addition, you could setup a local DNS cache (common in Unix/Linux system) to limit the number of DNS requests and make their statistical usage harder
geo localization:

of course your ISP knows where you are! As you have a contract with him he generally knows your address and your banking coordinates. Only some pre-paid mobile plans allow to by-pass this. As far as I am concerned, I would not worry too much about that point
communication data:

the rule is simple: all unencrypted data can be logged by your ISP. It include plain HTTP requests and their responses, as long as SMTP, POP or IMAP unless you use them over SSL. I will not speak too much of other (older) protocol like NNTP, Telnet, or FTP which are now seldom used and SSH/SFTP is fully encrypted.

=> here your should prefere HTTPS over HTTP, and only use mail protocols over SSL. For the mail part, you should also know that the mail provider has full access to all your unencrypted mails either sent or received. For example if you use Gmail, Google knows everything of your mailbox.

TL/DR: Some simple rules can allow a minimal protection of you privacy:

use a mail provider that you can expect not to sell too much or your data - neither Gmail nor your provider since the US Congress vote
always use SSL version for TCP protocols like SMTP, POP or IMAP
prefere HTTPS over HTTP

Some additional rules allows for better privacy at a cost of more complex configuration:

setup a local DNS cache to limit the number or DNS requests
use a VPN or TOR for browsing - and choose a VPN provider that you can expect not to sell too much of your data
use encrypted mail if the recipient as given you his public key


Should I be able to see patterns in a HS256 encoded JWT? I was fiddling with https://jwt.io/ using this header

{
  "alg": "HS256",
  "typ": "JWT"
}

when I realized that replacing the payload name with something repetitive like AAAAAAAAAAAAAAAAAAAA would produce a token such as this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFBQUFBQUFBQUFBQUFBQUFBQUFBIiwiaWF0IjoxNTE2MjM5MDIyfQ.hlXlWvaeyOb6OcrOwd-xfWgF8QlfmTycj5WWZwRr6FY

You can see that the BQUF substring appears to be repeated. The more As I added to the name, the more BQUFs show up.

As far as I know the presence of these kind of patterns makes it considerably easier to find out the encoded contents. What am I missing?

tl/dr: Your selected version of the JWT doesn't encrypt anything, it merely encodes it for easy
  transport.  The data in the payload is not meant to be a secret.

You have a JWS (JWT with signature).  What you are looking at is simply the base64 encoded data payload.  A JWS contains 3 parts:

The base64 encoded header
The base64 encoded data
A cryptographic signature

Base64 is simply an encoding format - not any kind of encryption, and is not meant to hide the data.  Rather, it just makes sure it is composed solely of standard ASCII characters that easily survive transfer between different systems.  As a result, if you were to take everything in between the two periods and run it through a base64 decoder, you would see your original payload data without issue.

The key therefore is simple: a JWS isn't meant to hide the data.  It is simply intended (through the signature) to ensure data integrity, i.e. if someone changes the data payload then you will know because your signature will no longer match.

Alternately you could use a JWE (JWT with encryption) to hide your data.  See Bob's excellent answer for a more detailed comparison between JWT, JWS, and JWE, all of which are closely related.


Help verifying downloaded Kali image I am following instructions as shown here

Operating Windows 7, so have downloaded GPG4WIN.
Next instruction: is to enter this command: $ wget -q -O - https://www.kali.org/archive-key.asc | gpg --import
So, newbie here, ...am I to enter that into Command Prompt? When I do I get error message: '$' is not recognized as an internal or external command, operable program or batch file.

The verification steps assume that you are already using Linux. As you're using Windows, you'll need to follow the manual verification steps from the Kali download page.

To run a SHA1 checksum on Windows, download and install Microsoft's checksum app. Per this page, run it with the command:

  fciv.exe -sha1 kali-linux-1.1.0-amd64.iso

Then compare the checksum by hand with what's on the Kali download page.

Update: 02 July 2017
Kali is now using SHA256 which is not supported by fciv. You can use PowerShell as suggested by @Rоry McCune in the comments. The syntax is

Get-FileHash kali-linux-2017.1-amd64.iso -Algorithm sha256

You may need to change the filename if you are using a different version of Kali.


A bot edited all pages on my Wordpress installation I manage a Wordpress site for an event registration. The site is only active for a few months a year. The rest of the year it's idle, as in it's up, but not actively maintained.

Now the time has come to prepare it again, and I noticed that all posts and pages have been edited. At the bottom of each page/post a script tag has been added. This tag creates a link to some website, if often links to domyhomework.com, or something similar.

All these edits was made by the same user thats only a "publisher", and not an administrator. It is clear that this user did not actually do this, but it's also clear that his account was used. The edits all happened on the same date, from 11:51 to 11:54.

I have changed the password for the user, as well as "log out all other sessions". I've also installed a more solid activity logger, that will monitor the site from now on.

I'd like to know what exactly has happened here, so that I can prevent it in the future.

edit: It feels like the user has malware on his computer and when logged into the site a script runs and adds this to pages/posts, but I don't know how to prevent something like that, or if that is possible.

Since your course of action was changing the password of the offending account, it seems that your theory of what happend is that that users account was breached (e.g. weak password was bruteforced live, reused password from a data dump, users computer infected by malware). That is one possible explanation, but it is not the only one, perhpas not even the likeliest one.

Another explanation is that there is a vulnerability in your WordPress installation, either in the core itself or in a plugin. If that is the case, changing a password is of little help. Your doors are still wide open and you are vulnerable. The compromise could be much worse than you expected - there may very well be some nasty malware running on your server right now.

You could try to figure out how bad it is by doing a forensics investigation. But it sounds like logs are scarce, and even with good logs this is still a tricky thing to do. So maybe the best course of action is to assume the worst.

I'd have a look at these two posts for further guidance:

"How do I deal with a compromised server?" for immediate response to the breach.
"How can I protect a Wordpress installation?" for how to secure your WP installation for the future. (There are many more resources for this on the web.)


Tor: I'm repeatedly being connected to a couple of Entry Nodes! I'm using Tor (Orbot for Android), and when I look at the log of the connection establishment phase, I see that I'm repeatedly being connected to familiar nodes, especially the Entry Nodes which 3 out of 4 times are the same 3 nodes that I'm connecting to every time! Even the whole 3 Nodes in my path are more often than not also familiar and so much so that I almost see no randomization process happening!

I understand that if 1 malicious node is in my path, my anonymity won't be much affected, but if at least the Entry and the Exit Nodes are malicious, then I'm not anonymous anymore since the entry data and exit data can be monitored and compared.

Question is:
How do I force randomization of the connection, and WHY am I being assigned these nodes repeatedly (i.e. is there a known attack in which an entity can deliberately assign users to specific ranges of nodes to strip them out of their anonymity?)

If you delete your Tor data directory, Tor will randomize how it builds new circuits and picks new entry nodes.

However, the behavior you are seeing is intentional.  Tor has affinity to a small set of entry nodes, called entry guards. These guards help reduce the chance that you are assigned an entry node which is malicious, because your computer is only connect directly to that small set of entry guards, rather than connecting at random to a different entry every time.

For example, if you start Tor every day for a year, with random assignment that would be 365 entry points and 365 opportunities for an attacker to be your entry node. Instead, by having just 3 entry guards, you only are placing your trust in those 3 nodes, only 3 random opportunities for your entry to be an attacker, smaller chance that one of your entries is an attacker.

https://www.torproject.org/docs/faq.html.en

  The solution is "entry guards": each Tor client selects a few relays at random to use as entry points, and uses only those relays for her first hop. If those relays are not controlled or observed, the attacker can't win, ever, and the user is secure. If those relays are observed or controlled by the attacker, the attacker sees a larger fraction of the user's traffic — but still the user is no more profiled than before. Thus, the user has some chance (on the order of (n-c)/n) of avoiding profiling, whereas she had none before.


Can a compromized browser know your ISP's IP even if using a VPN? Let's say you use a reliable VPN like ProtonVPN to browse the Internet. In theory, can a compromized browser betray you? Does it has access to your ISP's IP?
As a bigger picture, if you want to upload some sentive material, can a compromized browser track your activity and report to "someone", maybe with your real IP along?
I'm not referring to Chrome of course, but I consider any browser untrusted by default.

A VPN only protects the connection to the VPN exit, nothing more. It does not restrict what can be connected to and what information can be exchanged. A compromised browser could simply phone home through the VPN and submit all relevant information about what you are doing. A VPN will not prevent such phoning home but instead protects it like all the other traffic. Such a compromise could be as simple as using a malicious browser extension, which includes previously innocent extension which gone rogue.


How secure is the native browser password autofill? Safari, Chrome, Firefox, Edge, and IE all either have a suggest-password feature, or password archival feature.

How secure are these passwords when stored on a computer?
If replicated, how secure are they on the cloud host?

I would assume that 1Password, LastPass, or any of the many password apps would have this comparative information, but I can't locate it. This lack of information is making me think that browsers have since improved their security when I last researched this (in the late 90's)

Usually, not secure at all. It really depends on your threat model, but the data is usually saved:

unencrypted,
encrypted with a publicly-known passwords or
encrypted with a user given master password

On Windows (I believe 7 and over) Chrome uses an OS facility for the storage, which ties the encryption to the logged in user.

On Linux systems Chrome uses gnome-keyring or the equivalent in other desktops. The principle is the same as in Windows.

Firefox on the other hand avoids the use of OS facilities and takes care of the crypto and storage itself. If you set a master password an attacker would have to bruteforce it to get to the saved passwords(*). If you don't set a master password, one will be provided to you and it will be the empty string "". Not a very good password if you ask me.

In all cases the passwords are probably accesible to an attacker with code execution in the current user context.

In the case of Firefox without a master password the passwords are also accessible to an attacker with access to the database file.

This blog has a more in-depth analysis of the issues.

(*) As noted in the comments by Mrdeep, Firefox does a lousy job of hashing the master password, so it's easily bruteforced.


What exactly is digested in an S/MIME signated-only e-mail? What exactly is digested in an S/MIME signated-only e-mail?

It's definitely not only a sha256-digest of the original message, which means that

$ openssl dgst -sha256 <<< "Text"

would never create the digest that is created for a S/MIME mail with the exact same "Text".

I've read and tried to understand information about this in RFC 5751 (in section 3.4.3.2), but it's still unclear to me, what exactly is digested for a S/MIME e-mail.

How is the original message prepared and enhanced before being hashed and encrypted?

If I understood correctly, some CMS processing and transfer-encoding is done for preparation. Is it possible to put the entire process into easy words?

Notes like these (in section 3.1) are even more confusing:

  These (three) steps are descriptive rather than prescriptive.  The
     implementer is free to use any procedure as long as the result is the
     same.

How can different e-mail-applications even work together on a basis of such vague descriptions?

From RFC 5652, section 5.4

  The message digest calculation process computes a message digest on
     either the content being signed or the content together with the
     signed attributes.

But you can verify the (cms-)digest of the plaintext by hand:

Save signed mail from Thunderbird as Test.eml
Check message digest: $ openssl cms -in Test.eml -cmsout -print
Cut out plaintext from mail and save to Test.txt
Compare all hashes to digest from step 2: $ lua sha256-hash-finder.lua Test.eml "4db15ae843e3 ... "