It depends entirely on what machine you are installing the cert and what the certificates purpose is. For instance if this is a public cert it would make no sense for it to be password protected. This is one of those things that non-tech people will think sounds weird but when you know what it is talking about it is much more nuanced.
I am not taking shots at him - he is revealing something important - you are not getting what I am saying.
He is most likely pointing it out that it would only make sense if it was a public cert (i.e. used to verify identity on a remote host). He is asking why a public cert (not why is it not password protected)? (Hint: they are not supposed to be connected to the internet).
It’s supposed to be a 2 step authentication. The certificate is only one step- a physical token. You typically need a second step- PIN or Password that the user knows to have a complete authentication. I’ve used PIV card authentications and you ALWAYS need your card with the certs AND a PIN.
You would be absolutely shocked how many tools do this.
In most cases, it is because the developers are too incompetent to raise a prompt to an admin for the password at the moments crypto operations are required.
Or the crypto operations are so frequent, raising a prompt would bog down the system because it requires an admin or a very simple password everyone knows.
Most of the time they're at least self-aware enough to not ask you to store a plaintext password in a config file as that would be useless.
Rather than figure that out, they tell you not to use a password.
This is incredibly frequent in the software business when retard developers build something, then someone comes in later and says "ADD CRYPTO" so they do the laziest implementation possible. They're too stupid to hold the crypto operation open and continually shovel data through it, so instead the find some "write to disk/send to internet" function and wrap it in a crypto operation. Evewry time you access the key, it would require the password. Lazy fucks are lazy
There are plenty of times when you do not want a certificate to be password-protected (public certs). In this case my only curiosity is why the machine needs a cert (hypothetically public as this is not-password protected) at all if they are not supposed to be connected to the internet.
very likely that this operation adds a crypto signature to the results it creates to establish the non-repudiation requirement.
Even if it wasn't on the internet (it was) you still need to pull the data off the device at some pointand check a signature that the data was calculated on a device with a certain key at a certain timestamp for later analysis.
To your first part - I am following - but that you would expect to be password protected on the host (in this case voting machine cert is being installed on).
To your second part - correct but if you were pulling from the host and that was the point of installing the cert you wouldn't install the public cert on the host (as inferred by info we are given).
From what we are given in this post it is fishy the device needs a public cert at all if it isn't supposed to be connected to the internet.
I would hope it be password protected, but if it is, the app using the key would be required to prompt the user for the password every time it opens the key (obviously can't cache it).
The developers were too dumb or too lazy to implement a way to prompt the user for the password when the application needs to open the key.
Developers are the laziest fucks on the planet. Basically every web server on the internet removes the password from the crypto private key because developers can't be bothered to enter the password when they turn on the server (or know that putting the pw in a config is pointless).
The system appears in line with what would be required to implement a certifiable system (just stupidly implemented). Some trusted root certificate authority would issue a certificate against a request generated from Dominion's private key. The voting machine would sign some form of output with the private key (without a password bc they are lazy) and attach this trusted cert to the output. They need to manually import this because the system should not be connected to the internet and therefore can not resolve the trust chain automatically through the internet.
edit: Developers are lazy stupid fucks that should never be trusted with anything important. The only way to trust anything a developer does is complete transparency. Literally anything they obfuscate is something they're active hiding from you. Source: Managed both US-based and Overseas-based developers. Some good, some bad. They're all the same they all lie to you and try to hide things.
You can't freely share the certificate among many users when it has a password, without distributing the password, which immediately invalidates the certificate for all practical purposes. Also, it's because stupid people will write the password down somewhere, compromising the certificate immediately. With a no password certificate, it can be given to anyone, and they can then use the certificate to provide the necessary authentication to access a system, application, or device, and appear legitimate, or anonymous, depending on which type of nefarious activity is being committed.
It depends entirely on what machine you are installing the cert and what the certificates purpose is. For instance if this is a public cert it would make no sense for it to be password protected. This is one of those things that non-tech people will think sounds weird but when you know what it is talking about it is much more nuanced.
You only need a password if the cert has a key in it. If you try to export a cert without a key windows won't even prompt you for a password.
I am not taking shots at him - he is revealing something important - you are not getting what I am saying.
He is most likely pointing it out that it would only make sense if it was a public cert (i.e. used to verify identity on a remote host). He is asking why a public cert (not why is it not password protected)? (Hint: they are not supposed to be connected to the internet).
It’s supposed to be a 2 step authentication. The certificate is only one step- a physical token. You typically need a second step- PIN or Password that the user knows to have a complete authentication. I’ve used PIV card authentications and you ALWAYS need your card with the certs AND a PIN.
Or their “Proprietary Flash Drives” that keep getting stolen (PA) or misplaced for 30 minutes (Milwaukee, WI)
Yes, they have admin authority
You would be absolutely shocked how many tools do this.
In most cases, it is because the developers are too incompetent to raise a prompt to an admin for the password at the moments crypto operations are required.
Or the crypto operations are so frequent, raising a prompt would bog down the system because it requires an admin or a very simple password everyone knows.
Most of the time they're at least self-aware enough to not ask you to store a plaintext password in a config file as that would be useless.
Rather than figure that out, they tell you not to use a password.
This is incredibly frequent in the software business when retard developers build something, then someone comes in later and says "ADD CRYPTO" so they do the laziest implementation possible. They're too stupid to hold the crypto operation open and continually shovel data through it, so instead the find some "write to disk/send to internet" function and wrap it in a crypto operation. Evewry time you access the key, it would require the password. Lazy fucks are lazy
But for election systems
what
the
fuck
There are plenty of times when you do not want a certificate to be password-protected (public certs). In this case my only curiosity is why the machine needs a cert (hypothetically public as this is not-password protected) at all if they are not supposed to be connected to the internet.
public certs don't use a password.
Private keys may or may not have a password.
very likely that this operation adds a crypto signature to the results it creates to establish the non-repudiation requirement.
Even if it wasn't on the internet (it was) you still need to pull the data off the device at some pointand check a signature that the data was calculated on a device with a certain key at a certain timestamp for later analysis.
To your first part - I am following - but that you would expect to be password protected on the host (in this case voting machine cert is being installed on).
To your second part - correct but if you were pulling from the host and that was the point of installing the cert you wouldn't install the public cert on the host (as inferred by info we are given).
From what we are given in this post it is fishy the device needs a public cert at all if it isn't supposed to be connected to the internet.
I would hope it be password protected, but if it is, the app using the key would be required to prompt the user for the password every time it opens the key (obviously can't cache it).
The developers were too dumb or too lazy to implement a way to prompt the user for the password when the application needs to open the key.
Developers are the laziest fucks on the planet. Basically every web server on the internet removes the password from the crypto private key because developers can't be bothered to enter the password when they turn on the server (or know that putting the pw in a config is pointless).
https://serverfault.com/questions/160768/stop-apache-from-asking-for-ssl-password-each-restart
The system appears in line with what would be required to implement a certifiable system (just stupidly implemented). Some trusted root certificate authority would issue a certificate against a request generated from Dominion's private key. The voting machine would sign some form of output with the private key (without a password bc they are lazy) and attach this trusted cert to the output. They need to manually import this because the system should not be connected to the internet and therefore can not resolve the trust chain automatically through the internet.
edit: Developers are lazy stupid fucks that should never be trusted with anything important. The only way to trust anything a developer does is complete transparency. Literally anything they obfuscate is something they're active hiding from you. Source: Managed both US-based and Overseas-based developers. Some good, some bad. They're all the same they all lie to you and try to hide things.
And most organizations don't want to spend the money on an HSM, or some other private key vaulting configuration.
Exactly. For election systems, WHAT THE ACTUAL FUCK!?
It makes MiTM attacks easy peasy lemon squeezy. Reminds me of Hitlery's unprotected, illegal, private email server.
Where can we read the source document?
Thank you!
You can't freely share the certificate among many users when it has a password, without distributing the password, which immediately invalidates the certificate for all practical purposes. Also, it's because stupid people will write the password down somewhere, compromising the certificate immediately. With a no password certificate, it can be given to anyone, and they can then use the certificate to provide the necessary authentication to access a system, application, or device, and appear legitimate, or anonymous, depending on which type of nefarious activity is being committed.