We're setting up S/MIME so that we can send encrypted emails. However, I have a bit of a stupid (and maybe obvious) question...

If someone steals a password for either the sender or the receiver, wouldn't they be able to view those sent or received emails? If not, what's preventing them from doing so?

3 Answers 3


As far as I know, S/MIME doesn't use passwords, but private and public key pairs. So, the private and secret thing is user's private key. If private key is stolen, it can reveal the content.

If you want to prevent stealing privkeys you (or each user) should store them in safe place. If your privkey is stolen, you should asap revoke the certificate (with pubkey) and get new key pair.

S/MIME actually encrypts the message content with random symmetric key, which is encrypted by recipient's pubkey. Recipient then using his privkey decrypts the symmetric key and uses it for message decryption.

  • 1
    But the private keys on each end are almost certainly protected with passwords. If so, then the attacker not only needs to steal the private key file, but also the password. They will need both. Nov 20, 2013 at 19:02

When you say password, are you referring to the password for the email account, the password to secure the s/mime cert, or the smartcard password (pin)?

Ultimately the attacker needs access to the private keys so it depends how they're stored. If they're on a smartcard, then the smartcard must be present to perform the cryptographic operations. If they're stored on the system, the attacker would need that level of access too. If account credentials are compromised via phishing (for example), the attacker couldn't logon to web mail from across the globe and view encrypted emails.


S/MIME is not password-based.

(In fact, it is theoretically possible to do password-based encryption of emails using the S/MIME format, which is based on CMS, which supports password-based encryption, but I strongly doubt that there is an email software out there who is able to process that, let alone produce it. In practice, no password.)

S/MIME relies on X.509 certificates: the recipient has a public/private-key pair; the public key is made public (as the name says) as part of an X.509 certificate; the sender uses the certificate to learn (with some guarantee of ownership) the recipient's public key; the sender encrypts the email with the recipient's public key; the recipient uses his private key to decrypt the email. That's for encryption. For signatures, a similar process occurs, this time with the sender's own private key (to generate the signature) and public key (the recipient uses it to verify the signature).

If passwords are involved, then this will be indirectly, for private key storage. Private keys are where the power is. The user's private key is what enables him to decrypt incoming emails and sign outgoing emails. Stealing the private key of a user means stealing his power. So private keys must be well protected. In the whole S/MIME system, private keys do not travel, but we know that files on a given machine can sometimes be plundered (malware does that), so we prefer it when there is some extra layer of protection like, say, a password-based encryption.

In that sense, the password alone does not give much to the attacker; he still must access the actual storage space for the private key in order to recover the private key, which is his true target. At that point, things vary a lot depending on the situation. For instance, in an Active Directory world, when the users' machines are part of a domain, knowing the password for one user and talking to the AD server is sufficient to recover the user's roaming profile, which contains his private keys. Moreover, since a domain administrator can, on the AD server, reset the password of any user, then it follows that gaining administrator's privileges on that AD server is also sufficient to recover the user's private keys, even without knowing the user's actual password.

An additional point about S/MIME and encryption in a business setup: presumably, encrypted emails are for business, thus contain business data. Correspondingly, losing access to a private key implies losing the data. This happens, for instance, if a user becomes "unavailable" (he was fired, he was ran over by a bus, he ate bad clams...). The employee who replaces him must be able to read the stored emails of his predecessor, and this requires some sort of escrow system. The fact that a Domain Admin can reset a user's password and recover his private keys is thus not a weakness; it is a necessary feature. However, any key escrowing system like this one can become an additional entry path for an attacker.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.