* Username and Password fields must not autocomplete * Username and Password fields must not allow text to be pasted in to the field * Password must be at least 8 characters with lower case, upper case, numbers, and special characters (they didn't care it had a maximum length of 8 characters)
I straight up told our project management it was actively hurting our security, and was told the the point here was to fulfill a regulatory requirement to complete and resolve all issues from a independent "pentest" not to improve security.
They also flagged up that users can access JavaScript and CSS files. Not the original source files mind you, nor is directory indexing enabled or anything like that. They pointed to our compiled and minified app.js and app.css, and suggested we block access to these files as the source code to the app is “sensitive information”.
Having to tell a client another company they’ve hired are absolute clowns, without making it seem like we’re trying to save our own skin, is certainly interesting.
This isn't the time to tread lightly, but to go scorched earth. This isn't an "oh, we disagree on the finer points!" debate between peers kind of situation, but a flat-out "these knuckleheads are putting you at risk and you need to know it". You want to get the point across that you're not messing around or leaving room for doubt.
Source: have had these conversations several times over the years. I normally pride myself on tact, but in my experience tact is the exact wrong approach here as it gives the client the impression that there's a wiggle room of doubt.
“I’m sorry if this means we can’t do business any more, but this situation has gotten so severe, that I just have to tell you the unvarnished truth, and ….”
Hummmm. So a couple of years back, I was working on some internal tools that passed sensitive information around and I found some interesting info.
Some bloggers INCORRECTLY thought that HTTPS didn't secure the URL Flags. Correct fact: parameters passed in the URL like ?item=bla is encrypted
Also, some cloud providers aload Balancers (AWS) allow you to offer load HTTPS encryption/decryption - so there REALLY IS plain text stuff in the final leg of the journey (e.g. from the LB to the server)
In the end, the biggest thing I learned is that HTTPS is hard and it sucks.
It’s still good practice to keep sensitive info out of URL query parameters, which often leak into server logs.
At first I thought this must have been what they meant; perhaps there was some configuration thing we got wrong.
So we asked for clarification and nope, the example given was that someone logging in from an office could have their credentials sniffed freely by anyone else on the office LAN.
I sent the client back a list of government and military websites that responds to ping. As an extra bonus, it turned out the pentesters own website responded to ping.
Cheese, this one line in their report causes around 3 hours of meetings with around 10-20 people on them... and there were a lot of lines like this.
In the very last paragraph, as a conclusion to YOUR exercise, explain how the utter lack of competence in the subject matter displayed by the consultant has resulted in blah, blah, dollars, time, effort, all down the drain. Emphasize the harm to the organization and how it affects the trust required between different groups.
I guarantee it will get you promoted or fired. Which one depends on the organization and I expect you already know what will happen.
Interestingly, I checked a few big sites, and while Google doesn’t, Facebook and Amazon both use client-side encryption. Is it just to provide some extra protection for pwned users who have trusted bad certs? I’m no security expert, and I’m struggling to think of any real benefit.
For the JS/CSS thing, I have literally no idea.
> Offer the option to display text during entry, as masked text entry is error-prone.
And under 10.2.1:
> Support copy and paste functionality in fields for entering memorized secrets, including passphrases.
(... snip ...)
> Allow at least 64 characters in length to support the use of passphrases. Encourage users to make memorized secrets as lengthy as they want, using any characters they like (including spaces), thus aiding memorization. Do not impose other composition rules (e.g. mixtures of different character types) on memorized secrets. Do not require that memorized secrets be changed arbitrarily (e.g., periodically) unless there is a user request or evidence of authenticator compromise. (See Section 5.1.1 for additional information).
Oh, and that password? Not case sensitive.
What, you expect them to make a case-sensitive version of NTFS just to store your password??
The auditors are typically 10 to 15 years behind technical security expertise.
If I can play devil's advocate for a moment—isn't this just how insurance necessarily works? Your car insurance company isn't going to interview your teenage son; they don't care that he's a particularly mindful individual, who never speeds because he remembers the time a close friend died in a car crash. "The policy says 17-year-olds are high risk, pay us a zillion bucks a month."
Of course, guidelines that have literally zero value still have zero value. But they have to come up with something concrete...
Probably not, but they are there to be paid by their customers. Does the customer have to mark a checkbox on a regulatory form? Give the customer some answer which is not blatantly false or useless, get the money, come back next year.
It's because it's in some dumb regulatory pentest manual or something. OK.
