* Posts by RamblingRant

21 publicly visible posts • joined 28 Nov 2012

British banks consider emoji as password replacement

Thumb Down

Actually, the maths doesn't stack up.

They go on about replacing passwords but their comparison is against PINs. That's not exactly an apples to apples comparison...

A 4 digit PIN (numbers 0-9) is 10,000 permutations, 7,290 non-sequential permutations.

A 4 emoji "password" (44 possible emoji) is 3,498,308 non-sequential permutations.

A 4 character password (*just* upper & lowercase) is 7,311,616 permutations.

If you throw numbers into the mix too, there's 14,776,336 permutations.

So, even compared to the weakest of passwords, there are still 3.8 million reduction in the keyspace.

The notion that banks will replace the ATM PIN with this is just nonsense... most still use Windows XP for heavens sake.

Sage Pay anti-POODLE upgrade REDUCED security - briefly


Re: Hmm, having worked with sage/pay

Can I just reiterate, POODLE isn't the issue here... it's the 56bit export cipher which PCI DSS explicitly prohibits.

There is absolutely no justification for running it while claiming to be PCI compliant.

Burglars' delight no more: Immobilise UK secures property list


Putting it into perspective...

Hi Tom

I'm very grateful you've actually thought the risk through and I suspect you already know the following, but let me clarify a couple of points for everyone else.

In order to locate an item (or all items), you'd need to enumerate every possible combination, like so:

User 1

Cert 1, then 2, then 3, then 4 etc... until 28,000,000.

User 2

Cert 1, then 2, then 3, then 4 etc... until 28,000,000.

... and so on until you reach all 4.2 million members.

At first glance, that seems infeasible... but it all depends how smart the script is. There's no doubt it'd take many hours and almost certainly trip an IDS warning, but there are far more efficient ways to go about it.

For example...

1) We know there are 4.2 million members & 28 million records, meaning an average of 7 items per user.

2) It's also reasonable to assume many of those items will be added one after another, but we need a fair tolerance to account for edge cases. Instead of blindly searching every cert ID, we can limit the scope to 1000 records before & after the data from the previous attempt.

3) With each successful "hit", we're able to narrow the search space considerably.

If user ID 400 and cert ID 10200084 (10 million, 200 thousand and 84) is successful, we'll know to start user ID 401 from cert ID 10200085 and above.

That way, successful hits happen faster as the time increases, but also limits the amount of requests necessary to pull off the attack, reducing the impact of IDS/IPS constraints.

There's a wealth of other information an attacker could use to make the attack not only effective, but very efficient.

Keep a look out for the follow up article on the blog & BBC. This is the tip of the iceberg.


UK banks ill-prepared for return of the rabid POODLE


Re: A solution for Richard G

Worth mentioning, Santander are now vulnerable to POODLE/TLS... so please ignore above comment.



That's a tough one.

You'll struggle to find any recent (or accurate) assessments, as the only people that truly know are bound by *very* tight non-disclosure agreements.

About 12 months ago, I contacted every UK bank to ask for detailed information on how they handle passwords. Some were in plain text, others were "encrypted" but wouldn't discuss how. Of them all, First Direct (an HSBC company) came out on top. They wouldn't disclose exactly how they were stored either, but their responses to quite lengthy questions were broadly spot on... which helps instill confidence at least. Ironically, HSBC directly were one of the worst... so who knows ;)


Re: A solution for Richard G

That's easier said than done.

Purely based on a Qualys check, you'd pick Santander. Quite honestly, they would be the last bank I'd choose if security was a serious concern.


You'll find several of my articles dotted about, on net-sec, ThreatPost, Softpedia etc.

Virgin Media blocks 'wankers' from permissible passwords


Re: Updated, but

I'm looking at the right line ;)



Virgin Media have subsequently removed the list of "unacceptable" words from the javascript file.

They are still enforced by the server however. As I mentioned yesterday, password security almost pales into insignificance compared to this...


Only official response (so far) has been "we're not willing to discuss our encryption"


Re: Merde!

The filter is applied both in javascript at the client and on the server.

It's certainly not hashed at the client prior to sending though, and it's looking more doubtful it's hashed on the server either.


Re: er...

It is checked server side too.


Re: "the more heinous crime is that Virgin constrain the password length to 8-10 characters."

This is where it started...


You CAN'T bust into our login app's password vault, insists Roboform


Some great points and without wishing to argue, let me put your "that'll never happen" comment under scrutiny.

Have you considered your source of IV, MAC protection, block algorithm, memory dump mitigation?

You don't need a piece of malware written specifically to thwart your defences... it's often the seemingly minor things which catch you out.

For example, what happens if your PC crashes while your data is in memory? All those lovely creds along with a detailed trace are almost certainly written to your drive. Now you have to find where they are and safely destroy them. You can't control every aspect of even your own environment... it's one of the reasons "roll your own" attempts fail.

I'm not saying you're wrong, just that it's a bad idea in general. If it works for you and you're mindful if the risks, you're still safer than most.

Security is always excessive until it's not enough. There has never been a valid "that'll never happen" or "chances are zero" argument... and there never will be.


Re: useful alternatives to the usual - gpg4usb or locknote

Sorry DMDeck16, but that's a really bad idea... and probably not for the reasons you'd think.

Your data is most at risk when in plain format... for example, when you need to sign in somewhere. The associated strengths of LockNote/GPG4USB or indeed any app you choose pale into insignificance as soon as you've decrypted your data.

Although all password managers use different storage techniques (passcards, databases, keychains et al), they all share something in common... they store each record separately.

By keeping all records in a single text file, you're encrypting & decrypting masses of data which for 99% of the time, you don't need. For instance, logging in to Facebook via Roboform decrypts only the credentials required for Facebook. Putting the rest of your credentials in memory only increases the risk.

If you go down the route of "store each LockNote/GPG4USB file separately", you're basically creating your own password manager. Trust me, the chances of you doing a better job than (for example) 1Password are slim to nothing. That's not a slight at you personally either... but good password management is about more than applying AES to everything in sight.


Re: I use FTP to store stuff on the Internet

WinRAR encrypt isn't particularly strong, and using FTP regardless of password size is insecure because passwords and data are transmitted insecurely (plain text). Use SFTP instead, if supported.


@Steve Knox

Agree 100%.


I use 1Password and at the moment, I wouldn't touch anything else. Dashlane is a close second, but it's not mature or well-rounded enough just yet. LastPass is pretty good too, although their bookmarklets are insecure and I personally don't like auth/decryption being handled in the same location as the data (the portal). There's nothing particularly wrong with that method, I just prefer most of the process being handled offline while still leveraging the benefits of cloud sync.

Re #4 (verifiably secure) - You're never going find anything which is absolutely and conclusively "secure", what matters is security in response to risk. This is where 1Password shines. The design and implementation are measured responses by experts to whom the word "security" means more than wrapping text in AES. There are "risks" with 1Password, I actually demo'd them before I purchased it (see blog under "Forgot your password? You're doing it wrong") but when you quiz AgileBits (makers of 1Password) they respond honestly and transparently. Trust is everything in this industry. Try the 30 day trial, ask AgileBits the same questions I asked of SiberSystems... compare the responses.

Re #5 (Trust) - This is difficult. If you're going to use a PW manager, you have to trust someone. I'm a firm believer in Kerckhoff's principle which (paraphrasing) says a system should remain secure when everything about it is known to everyone, other than the key. If a company will not openly discuss the way they protect your data, walk away. It doesn't necessarily mean it's inherently insecure, but it could be an indication that they haven't quite grasped the concept fully. If you spot something, no matter how trivial... ask questions. If something doesn't make sense (for example when "we never get the key" suddenly becomes "we get the key, but we don't keep it"), seek advice or walk away. Most importantly, look for security reviews... not just reviews. What prompted the early release of this blog was a tweet by TechRepublic (see bottom of article) which said "Roboform is enterprise-worthy". Trouble is, it was a comment by a respected journalist... so convincing users otherwise is difficult.


You're pretty much right. It doesn't so much default to true... it simply checks if the param exists and loads the PIN entry screen. If it doesn't exist, it loads the app as normal.

ICO plugs XSS vuln in its website. Only took watchdog FIVE YEARS


Re: (Re)Curses!

Harsh but hey, if it makes you feel better.


Re: Missing the point

With respect Richard, I haven't missed the point at all. The ICO don't collect/retain sensitive information by design... a design which can be altered by anyone using XSS.

The point is, the genuine ICO site may have been collecting personal information for the last 5 years... they just wouldn't know about it. In the screenshot above (twitter link), I've replaced the entire page with a fake article, but it could very easily be a malicious form which forwards the data to a remote location. As the data never hits the ICO's server, they'd be none-the-wiser.

Highly unlikely, sure... but possible. This is the lowest of the low hanging fruit and the ICO missed it, several times. The altruistic notion of the ICO "protecting us", from a technology standpoint at least, is laughable. The site had both stored & reflected XSS and an SQLi exploit in the data protection register, ironically... not to mention the SSL failures late last year. It's shambolic to say the least.

Model of best practice? Give me a break.


Re: (Re)Curses!

Funny you should mention that Frankee...


Got a Netgear router from Virgin Media? Change your admin password NOW


Re: Not quite sure why all the downvotes.

I hope it's not an N66U, or you've jumped out the frying pan, skipped the fire and landed in a volcano.

Use strong passwords and install antivirus, mmkay? UK.gov pushes awareness campaign


Quick review of this site for you good folks... with advice on KeePass & IdentitySafe.


Companies House website security 'a bit of a mess'


Re: False assumptions?

I look forward to the book ;)

It's a good point though; which makes it all-the-more important to ensure that nobody can change details without authorisation.

Thank you John for publishing this story.