New answers tagged

0

The other answers show how disclosing this is not a security issue. I will argue with a true anecdote that not disclosing can lead not only to frustrating users but even to less security. This happened to me more than once on sites that didn't make clear what characters are allowed. At that time I didn't use a password generator so I had a mental scheme to ...


38

Creating a psychologically frustrating situation for users could incline them toward less secure decisions. For example, they try to write a password in Swedish, but your input refuses the character å without explanation. Instead of picking a different good password without å, they throw up their hands and use password123—one that's easily defeated with a ...


0

I don't see a problem in disclosing the set of characters the user is able to choose from, as long as these rules are on the one hand also enforced and checked. Which is to say, if the user is not allowed to use \ in the field, it is not enough to check this in the JS input, but also before entering this i.e. in the DB and when the data is used. So the rules ...


9

Obscurity is not security. A good system is secure even when an attacker knows everything about it. In your case, paring down the wasted cracking guesses by a certain percent, say 25%, should not make-or-break the practicality of cracking: 1 trillion years is just as practical as 0.75 trillion years. Having implementation details not occluded also helps new ...


18

It depends. If the message describes an error from the normal users point of view, like "The 3rd character must be a digit", it is not a security vulnerability. But displaying regular expression used for validation means disclosing implementation details which can be a weakness, e.g. some libraries use recursive calls extensively and some expressions can ...


124

... that could be useful in an attack but is normally not available to the attacker Knowledge of invalid input characters are useful but can easily be found by the attacker with just a few tries. Thus this information is not really secret and keeping all users unaware of what exactly went wrong does not actually deter attackers, it only keeps innocent users ...


8

This is just one of the many scenarios where security tradeoffs are expected in favor of the usability of the system. However, there is a huge difference between showing stack traces (poor error handling), and disclaiming which characters are expected or prohibited in an input field. For most scenarios, one can argue that disclaiming which characters are ...


0

Your basic understanding is fundamentally correct: You have a media file or a media stream, which is encrypted with a symmetric key (almost always an AES-128 variant). Users who want to play back that stream need to obtain a copy of that key but, just as crucially, need to have a piece of trusted software and trusted hardware. An example of that is the CDM ...


1

(Disclaimer: My POV can be slightly biased by the protection I tried to crack, I sometime speak about stuff I don't know, I presume it work this way because I know similar DRM tools working like that) Conor is right: Speaking about DRM in general is far too broad: You speak about a server in your question but one of the most used copyright content doesn't ...


2

If the above is the case, I assume that an attacker could simply edit the binary for the CDM to access the key or the file after is decrypted. That's why a lot of DRM systems are not implemented on Linux systems ... To be able to run a DRM, the player must be "certified" by the DRM provider and must provide some secure way for this set key/decryption ...


Top 50 recent answers are included