New answers tagged

1

Say, 256-bits of randomness and 256-bits of signature, is that any more secure than just using 512-bits of randomness? It is not any more secure. The best case scenario for the signed token is that the attacker don't know anything about what would be a proper signature. That effectively makes it a 512 bit ranom number from the perspective of the attacker. ...


0

There are two ways to sign the token: You can sign the email envelope, but your password reset server only receives the raw token, the token is only used to prevent the email from being tampered. For example, an attacker might tamper the password reset link so they redirect to the attacker's domain instead of your real domain. The attacker can then present ...


0

If you have a database at your end where you can check that random number to ensure that it's the one you really sent, then not really. A more important consideration in a scheme like that is that your numbers come from a strong cryptographic quality source of randomness, otherwise an attacker might guess what someone's password reset code will be! A ...


1

What your partner said is somewhat legit and ok from security perspective. TLS is established between client HTTPS library and TLS server, not server app! Server app delegates TLS stuff to TLS server (Apache, IIS, dozens of them). Partner is planning to ignore certificate errors at TLS level (between client and web server). Instead, they apply certificate ...


-3

Confidentiality is ensured as a consequence of digital signature. That is once the browser validates the signature, then it trusts the server and uses the servers public key to encrypt messages to it, thus ensuring confidentiality.


3

The problem WYSIWYS is trying to prevent is that, when the same file is displayed with different software, or at a different time, or on a different system, etc, it may be displayed differently, even though the binary data is the same. Imagine someone crafting a web page that displays differently in different browsers. If someone downloaded it as an HTML ...


1

Assuming the question is " "How can I prevent a customer from installing their own firmware?", industry standards regarding this issue are (in short): Use a secure bootloader that would only accept to boot on a firmware that is signed with your key. Use a secure storage (also called fuses, or OTP (one-time-programming)) to store this key so that it just ...


3

Put multiple public keys in the firmware, with the corresponding private keys stored in diverse locations. Require that updates are signed with all of the private keys, not just one key. Never bring the private keys together, not even for code-signing — instead, move the code around between the locations where the private keys are stored so that each one can ...


1

Signed requests can help in the scenario where the Assertion Consumer Service URL requested after authentication can be to a variety of domains or URLs. To avoid being used as an open redirector, the IDP would generally validate based on a predefined list of valid URIs. This list would be obtained from the SP metadata or manually entered from a known list. ...


0

I had to remove my answer because it was flat out wrong: the PKCS#1 v1.5 scheme for signatures used by OpenSSL is only used partially (thanks Dave for yet another insightful comment). That also means that is doesn't hash the input - but that means that it doesn't fully respect the security claims of PKCS#1 v1.5 and upwards either for that scheme. So it ...


0

He should still sign the e-mail. While you are correct in saying that the certificate itself cannot be forged since it already contains a digital signature from the issuing CA it is still arbitrarily copyable. A signature on the E-Mail (or any other document) adds the proof, that subject actually does know and control the private key and is able to use it ...


5

Well, in theory you would be right. In some very specific cases those hashes would not be completely broken. However, you would need to be extra cautious, and supposedly some "self-generated" data could actually be insecure. Would you consider the check's written by the accountant to be self-generated by the accountant? Apparently yes, but it actually ...


12

Xander's answer is fundamentally correct: the issue is getting someone else to sign a benign message and use the signature for the malicious one. It is worth noting that although when you make a collision you don't get to decide on the messages directly, you often do get to decide on part of the message. For example I couldn't persuade you to sign "My name ...


15

Digital signatures are designed to do three things: Ensure the integrity of the data that has been signed Create some degree of non-repudiation by the signer The purpose you mentioned, which is to authenticate the origin of the message The biggest issue with hash functions that are susceptible to collisions is that you very quickly lose the first design ...


6

No, but. Yes, technically you sign (or decrypt) with the privatekey, not with the certificate itself. And a publickey certificate never contains the privatekey. But a lot of software, and thus documentation, and other description, blurs this distinction. We generally use a privatekey with a certificate (with the exception of SSH, where we attach limited ...


0

The safest method is to have the Users generate the keys. The Target and the Backend Server can then verify the origin of the package (which User made it) and the authenticity (if it has been tampered with either due to issues in transport or maliciously) without having to trust the specific origin of the packages. If you want Targets to be able to use ...


1

You should provide the user with a message digest (ex - sha256) so that user can validate the accuracy and completeness of software. Digests are designed in a way that even a single bit flip in your application will result in a different digest. You can calculate the sha256 digest using following command on a mac machine (Tested on mojave) openssl dgst -...


2

Yes, this is possible A security challenge for the Web Authentication API can by any byte array (of at least 16 bytes), and it will be signed by the clients secure private key. It can therefore also be used to sign documents or messages of all types by passing the document as a PublicKeyCredentialRequestOptions.challenge in the call to navigator.credentials....


Top 50 recent answers are included