Posts by Paul Moore 18 publicly visible posts • joined 3 Aug 2015
Responded quickly?! Did the right thing? How dare you!
I warned you 12 months before the hack happened (https://paul.reviews/value-security-avoid-talktalk/). You not only ignored me, but lied repeatedly when pushed for answers. You are an absolute disgrace and your involvement with the NHS sickens me. Your arrogance and complacency cost you, TalkTalk and shareholders £60 million; money which could be been saved had you listened from day one. Instead, you remained hidden behind PR/legal; endlessly citing your "best practices" and "squeeky clean" approach to security. When the dust settled, you left with a pay out. Donating to charity is admirable, however donating to people who, to this day, still receive & fall for foreign scam calls as a direct result of your incompetence would be more preferable.
You deserve to be investigated, possibly criminally, for your complete and utter failing to effectively protect the very customers who contributed to your vast salary & bonus.
I'd also invite whomever was responsible for your hiring to be investigated too.
Hi Will
Algorithms like bCrypt limit password length to 72 characters, though many people use SHA256 to "pre-hash" the input in a futile attempt to increase security. Even algorithms which don't specify a max limit can adversely affect performance at higher numbers, thus forcing a sensible limit to be imposed by the developers.
I won't bore you with chapter & verse, but it essentially boils down to this.
If your password is chosen at random (ie - by a password manager, not a human) and you're allowed to use mix-alphanumeric (a-z, A-Z, 0-9), there's no appreciable security benefit between 15 characters and 500, even if the site uses something as weak/broken as MD5. 62^15 (62 possible characters - to the power of 15, the length) is such a monumental key space, it's already computationally infeasible to break. Adding another 15/30/50/100 characters is technically "more secure" but in terms of mitigating real-world risk, there really is no benefit at all.
But...
If a site limits the character set (for example, you can't use uppercase), the length must be increased to make up for the loss in entropy.
log2(26) = 4.7 bits of entropy per character (26 being a-z)
log2(52) = 5.7 bits of entropy per character (52 being a-z, A-Z)
To achieve 80 bits of entropy (very strong, sufficient for financial transactions etc), you'd need 17 characters with just lowercase... or 14 with upper & lower.
I recommend 50 characters because it strikes a balance between robust security & performance, as modern hardware can churn through a 50 character password almost as quickly as 15 characters.
Cheers
Sorry David, but your explanation of password hashing is entirely wrong.
You cannot "decrypt" a hash. It's not enciphered, it's digested/hashed... it's dangerous to swap the terms "hashed", "encoded" and "encrypted", as they're entirely different principles.
If you're looking for a message digest algorithm, SHAx will serve you very well. If you're after a password storage algorithm, never *ever* use MD5/SHAx etc. It is not intended to be used to store passwords in a secure fashion.
Research sCrypt, bCrypt, Argon2i or PBKDF2; something which adds a significant work-factor to generating the hash. SHAx may be cryptographically secure, but it's not computationally secure (MD5 is broken on both counts). Each login needs to consume sufficient resources to slow the hash generation by 0.2/0.5 seconds but not enough to burden the server in the event of an attack/load. It's important to establish a happy medium for your server, mindful that algos like PBKDF2 reach the point of diminishing returns very quickly. For example, there's little appreciable difference between 100,000 and 200,000 iterations in terms of actual, real-world strength.
Set a reasonable password length limit (50 is plenty with no other constraints), validate the input meets any strength requirements and hash the input. Never derive any other data from either the original secret or the output digest (think Ashley Madison) and don't force the user to change their passwords at regular intervals. If you must use "security questions" (I highly recommend you don't), treat the answers as you would a password.
I absolutely agree with you... people should be held accountable for their actions, but with one caveat.
The definition of what constitutes a long, strong & unique password varies immensely. In an ideal world, we'd all be using password manager-derived PWs, cryptographically secure keys and patch frequently but one could argue that your point of view, though perfectly valid, bares little resemblance to how the industry actually works. As much as we'd love them to do so, people don't always follow best practices. There has to be some level of responsibility on behalf of the vendors to protect yourself, from yourself. If you make a change (intentionally or otherwise) which potentially impacts upon the security of that deployment, make it known. If they skip it, sure... they should be held accountable.
What isn't up for debate however, is the security of:
Username: 1
Password: 1
... but the Snom is perfectly happy to accept those as credentials necessary to protect the device.
Security should be enforced by those who understand it, not delegated to those that don't.
True, but that somewhat misses the point.
As you rightly said, default & weak passwords are bad... yet virtually every manufacturer is perfectly happy to ship devices which operate under such circumstances.
Clearly, telling people to use long, strong & unique passwords (alone) isn't enough. It's not beyond the realms of possibility to limit functionality *until* solid security practices have been followed; it's not much to ask.
"it's a matter of *if* your phone has a weak or no password"
It's sadly not a matter of *if*. Most people use comparably weak passwords for their bank, do you think they've given a moments thought to choosing a secure password here, if they've used a password at all?
"*if* you go to the right webpage"
You're right, but that's easy to achieve. It's also true of XSS & SQLi and I presume you wouldn't argue the severity of those, surely?
"*if* they know the IP address of your phone"
Not necessary.
"*if* they know the make of phone you use then"
Unless it's a targeted attack (even then, it's trivially easy to find which devices they use), the script couldn't care less which phones you use; it'll scan the network and if it finds a vulnerable device, it'll run.
The video is a demonstration that it's possible, simply by visiting a website... it's not intended to provide a step-by-step guide.
Hi Paul
There was a working prototype back in Nov 2014 when EveryKey hit Kickstarter, but it bares little resemblance to what is being offered today.
https://www.kickstarter.com/projects/everykey/everykey-the-wristband-that-replaces-keys-and-pass/description
The original purpose of their first crowd funding campaign was to "fund their first production run", suggesting all the R&D, quality assurance and prototyping niggles had been ironed out already. In truth, backers paid to entirely redesign the product. To add insult to injury, at no point was it mentioned that EveryKey needed a further $1 million dollars to complete the project. Unfortunately, the contractual obligations of those investments forced EveryKey to launch another Indiegogo campaign, presumably to sell a minimum amount within a certain time after funding.
None of the standard, stable-build UAs currently block requests to an RC4-only site... so there's no issue there. If you run a bleeding-edge build of any browser, you're opening yourself up to far greater risks... something which vendors will actually tell you. To subsequently criticise a site for "unnecessary security risks" is bordering on comical.
Attacks against RC4 are still incredibly difficult, requiring 2^26 sessions encrypting the same data with different keys... that's over 67 million requests! If you're logging in 67 million times, you probably have more serious issues.
Yes, RC4 is broken. VM are aware of it and working towards a solution, but all this "think of the children" FUD is helping nobody.
The CCS vulnerability is the cause of the Qualys "F" score, not RC4... though both need to be fixed.
However, that only addresses access to the site. If you look at their email TLS deployment (https://starttls.info/check/cjsm.net), it's even worse. There's support for SSLv2, SSLv3 w/POODLE, a self-signed certificate and a 1024 bit key. All things considered, it's about what I'd expect of a gov't service; insecure, outdated and managed by the lowest bidder.
SSLv2 was deprecated in 1996. To claim it's "secure" is absolute nonsense.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
