Hot answers tagged

14

Good question. I'm a Native American, and this is pretty well-known to us. I also have experience with Chinese language and dialects. I'll explain why I'm mentioning the Chinese part later. This is a very good example of security through obscurity. It works until it's figured out. However, there are so few Navajo speakers compared to English speakers, ...


6

Refer to the guidelines set up by the CA/Browser forum for extended validation. 8.5.1 General The CA MAY only issue EV Certificates to Applicants that meet the Private Organization, Government Entity,Business Entity and Non-Commercial Entity requirements specified below. 8.5.2 Private Organization Subjects An Applicant qualifies as a ...


6

In addition to @Mark Buffalo's excellent response, there's another aspect - For some communications it is sufficient to delay the adversary's access to the data, rather than to deny it. The 'Security through Obscurity' nature of Code Talking is sufficient to this limited goal. Code Talkers, like the Navajo in the Pacific Theater, and more recently the ...


3

One option: They can clone the whole system to a computer or another phone. After that, they will do the tries. After it wipes itself, they will clone it again. Second option: If it is the data what is going on, they can copy it to a PC and crack it there. No wiping applies on that in this case ...


3

The trailing = usually proposes that it is encoded (not encrypted!) using base64. You can decode it simply as from Linux shell (or there are some web tools): echo "Wmd5emhzIHhya3N2aSBkemggbGlydHJtem9vYiBkaXJnZ3ZtIHVsaSBnc3YgU3Z5aXZkIHpva3N6eXZnIHptdyByaCB6IGhrdnhyem8geHpodiBsdSBnc3YgenV1cm12IHhya3N2aS4gR3N2IHVvenQgcmggemd5NGhzMWhoMGgxbmtvMw==" | base64 -d ...


3

In that case you generate a random symmetric key for each message and use that symmetric key to encrypt the message. Then you encrypt one copy of that symmetric key per recipient with the key of that recipient and attach these to the message. So the message will contain of: symmetric key S encrypted with public key A symmetric key S encrypted with public ...


2

This is a compile-time option, not a run-time option. If you run ./configure --help on the cryptsetup source code, it'll reveal that --with-crypto_backend=openssl will do what you want.


2

The usual way this is done in PGP etc is to create a symmetric key and encrypt this key with the public keys of each recipient. The original message itself will be encrypted with the symmetric key. Thus the result includes the encrypted message once (single key for all recipients) and then the encrypted symmetric key (short compared to the message) for each ...


2

While it definitely does provide a degree of security, it still leaves you a number of security holes that may or may not matter dependent on the type of application you are developing. For a non-exhaustive list: Content may meant to be limited to a select group of users, what if one of them leaks the URL? URLs with GET parameters are stored in a large ...


2

Anything what the browser can do without human intervention can be automated. This might be done from outside by looking at the code or one might simply control the normal browser with Selenium or similar tools. Since you will pay users for visiting the page the chances are high that somebody likes to earn easy money and will automate the visits.


2

First, SSL stopped at version 3.0, which is massively flawed. TLS is currently at 1.2 (plus a lot of activity in the TLS 1.3 working group). This is generally a matter of acronym - hopefully when you say SSL encrypted, you actually mean TLS, and you specifically mean TLS 1.2 with AEAD ciphers. Second, for TLS of any type, both protocol version and cipher ...


2

FormsAuthentication.Encrypt() now uses the encrypt-the-MAC pattern over both the IV and the ciphertext, so yes, it is done correctly now. As a side note, it does depend on the machinekey element to determine which encryption and MAC algorithms are used, it's worth double-checking your configuration to ensure you're configured to use either AES or Auto ...


1

One tangible example is timing attack on string comparison. It works by measuring how much it takes for the application to compare 2 strings. The default string comparison implementations in nearly all programming languages are optimized and they work by comparing 2 strings character by character and they alert a mismatch as soon as they see a difference ...


1

This is a base64 encoding followed what seems to be a substitution cipher. Since it is monoalphabetic, it should be easy to crack. Have fun: http://www.cryptoclub.org/tools/substitution_cipher.php


1

Use of long random tokens as secrets to provide access to a file can provide effective security. I'd recommend 128+ bits to make it truly outside the range of randomly guessing. You could probably get away with fewer bits, especially if you rate limit IPs based on bad guesses. E.g., if you had a 64-bit or 80 bit token and a billion such files and were ...


1

These types of questions come up from time to time. Essentially, this is security by obscurity. The fact that it is hard to guess only addresses one type of issue. It does not protect against: Users accidentally sharing the link, bookmarking the link, etc. The user accidentally typing the url into Google or another search engine, resulting in it being ...


1

As already stated, this is that way by design. Probably MSDN article could (or should) be more explicit about that. The way you extracted the "signed" data is wrong. The XMLDSig documentation is clear about it. You may want to read section 8.1 of this link https://www.w3.org/TR/xmldsig-core/ Just as a user should only sign what he or she "sees," persons ...


1

XML Signature are prone too many attacks. That is due to the way XML as a file format is defined and how it is implemented by (parsing) frameworks. https://www.owasp.org/images/5/5a/07A_Breaking_XML_Signature_and_Encryption_-_Juraj_Somorovsky.pdf https://lists.w3.org/Archives/Public/public-xmlsec/2009Nov/att-0019/Camera-Ready.pdf


1

To me, this seems not really as a error of the protocol but as wrongly used. You get a part of the XML using Doc.SelectSingleNode("/message/msgenvelope") but you never checked that "/message/msgenvelope" is actually the signed part of the XML! You have to treat the XML more like a file system with different files and not like one entity. Think like this: ...


1

Apparently the sessionStorage is not really cleared when closing the tab. It is easily revived by clicking on "Reopen closed tab" I've written more about it in here: http://blog.guya.net/2015/08/25/the-never-ending-browser-sessions/



Only top voted, non community-wiki answers of a minimum length are eligible