When we sent a password through Internet, for example to our client once we have finished a project, we must pay special attention towards attacks and password thefts.
A good practice would be sending the data separately, that is, we must avoid putting together account name and password in the same message. Besides, if these messages are separated sufficiently in time means that a potential attacker must keep capturing messages the same amount of time, on the contrary he or she risks losing half of the access information. This requires having previously talked about it with the client, otherwise we will be expecting for the client to know that the data that we have sent to him or her separately is related to each other. We can not assume it or we risk having an unsatisfied client that has not received the password or a way to manage his or her product as an administrator.
A tool that we can use is Gmail, from Google, Gmail messages can be encrypted at several levels:
Another useful tool for this task is Enigmail, an add-on for Mozilla Thunderbird. It allows us to encrypt our messages with OpenPGP, that is, PGP, meaning Pretty Good Privacy. PGP uses symmetric and asymmetric encryption at the same time. First, it generates a single session key and, using a symmetric algorithm, encrypts the message. On the one hand these algorithms are quick to use, the downside is that they are also easy to attack when the message and the session key are broadcasted, if we do not protect this key or the algorithm used we are exposed. The session key is encrypted using the public key of the recipient and the message and the encrypted key are sent. The recipient only has to decrypt the session key with his or her private key and then use it to decrypt the message. You can download Enigmail from its website.
We have not used any of these methods because the characteristics of this product allowed it. To share the YouTube channel with the client adding to it the email account that he has given us and giving him or her the owner's permission is enough. Even so, it would be useful to use S/MIME with the client's electronic certificate, for example, to verify that the email account actually belongs to him or her, or vice versa, so the client rests sure that he or she is communicating with us.
A good practice would be sending the data separately, that is, we must avoid putting together account name and password in the same message. Besides, if these messages are separated sufficiently in time means that a potential attacker must keep capturing messages the same amount of time, on the contrary he or she risks losing half of the access information. This requires having previously talked about it with the client, otherwise we will be expecting for the client to know that the data that we have sent to him or her separately is related to each other. We can not assume it or we risk having an unsatisfied client that has not received the password or a way to manage his or her product as an administrator.
A tool that we can use is Gmail, from Google, Gmail messages can be encrypted at several levels:
- S/MIME: meaning Secure/Multipurpose Internet Mail Extensions, it allows encrypting emails with the principles of asymmetric cryptography, public and private key. This is possible if Gmail knows the public key of the recipient, then it encrypts the message with this key and finally the recipient is the only one who can decrypt it with his / her private key. It is also possible to link an electronic signature to the message, upon arrival this signature will be verified against the public key of the sender to ensure that the message is not falsified. Its identifier in Gmail, see image 1, is a green padlock.
- TLS: meaning Transport Layer Security protects similar to S/MIME, but this time the channel for the message is ciphered, not the message itself.this is done, once again, with the public and private keys from both parts. Its identifier in Gmail, see image 1, is a grey padlock.
- Without encryption: without any type of encryption the messages are not safe, it is not known if the sender has been falsified or if a possible attacker has intercepted them, sensitive data should avoid this method of communication. Its identifier in Gmail, see image 1, is a crossed red padlock.
 |
| Image 1. Description of the types of encryption according to Google. |
We have not used any of these methods because the characteristics of this product allowed it. To share the YouTube channel with the client adding to it the email account that he has given us and giving him or her the owner's permission is enough. Even so, it would be useful to use S/MIME with the client's electronic certificate, for example, to verify that the email account actually belongs to him or her, or vice versa, so the client rests sure that he or she is communicating with us.
No comments:
Post a Comment