Here's how 5 mobile banking apps put 300,000 users' digital fingerprints at risk Massive amounts of private data – including more than 300,000 biometric digital fingerprints used by five mobile banking apps – have been put at risk of theft due to hard-coded Amazon Web Services credentials, according to security researchers. Symantec's Threat Hunter Team said it discovered 1,859 publicly available apps, …
Still not good enough and terrible security practice. Worrying that 98% were iOS apps as users on that have a impression of greater security from the platform which is heavily eroded if a lot of developers tend undo a load of good work by being lazy.
Well, colo[u]r me stupid, but my (limited) understanding is:
1 - either the server expects the hashed data, in which case the hashed data is, for all intents and purposes, the password/authentication token/etc, so the hashing process was completely pointless and adds no security
2 - or the server expects the plaintext data, but the app writer thinks that he/she is being clever by hashing the secret instead of storing it plain in the app, and unhashing before transmission. Which is pretty pointless, because the key must also be in the app, so you're adding minimal additional security by hashing.
Note that salting is irrelevant, for 2 similar reasons, which I won't bother to repeat.
Basically, if you need a secret to access a resource on the server, and you store that secret in your app somewhere, then you have to hope that (a) the attacker can't reverse-engineer your app, and (b) that the attacker can't break into the keychain and decode your TLS data to the server. And we all know at least one laptop manufacturer has done exactly that, and it would be pretty dumb to assume that your phone manufacturer hasn't done the same thing.
I think. In any event, I refuse to have a mobile banking app on my phone, despite regular requests from my bank.
This post has been deleted by its author
My reading of this is that this is not to do with passwords in the keychain, it is effectively retrieving a password from a code library, in much the same way that you call a library to (say) render the properties of a button. It is just part of the underlying coding of the app.
I would hope that any software libraries, SDKs, etc. that are used when security is concerned are audited and not simply accepted as trusted.
Similarly, there should be a formal development process in place that verifies that the project's security requirements are satisfied (including that "dead code" / unused code / test code is not present).
It always surprises me that processes from the safety domain that are also of relevance to security-related projects are generally not adopted (and that "safety" and "security" are seen as being different).
"I would hope that any software libraries, SDKs, etc. that are used when security is concerned are audited "
They never are, primarily because they're taken on trust, and in any case the expertise required is not available at the point of use. It's even more problematic where libraries are accessed dynamically from remote repositories, as contamination at source can occur at any time. Both dynamic access to remote libraries and their contamination at source are on the increase, and this is the primary paradox of the web. Even as the demand for security grows with applications being applied to ever more sensitive purposes, actual security diminishes due to ever greater susceptibility to malicious action against the required resources.
Difficult not to conclude that this much of this is professional negligence and in breach of data protection regulations in many countries. It's certainly in breach of AWS' terms and conditions to hard code credentials making companies liable for any data exfiltrated.
You must always authenticate before you authorise.
Bland statement from the HackedBank: our bank were the subject of a sophisticated attack whereby state-backed actors discovered our hard baked credentials. A very small number of our customers were affected. We treat our customer. data and security very seriously. Blah blah blah.
Genuine question, as the article does not make this clear. As far as I know, Apple's TouchID and FaceID don't allow apps to grab fingerprints or face scans. That data always stays on the device (which is why when you switch iPhones you always have to set it up again)
Instead, when an app requests authentication, all it will get is a "yes" or a "no" (Apparently in the case of TouchID iOS won't even tell *which* finger was presented, just that *a* valid finger was presented) but certainly not the data the scanner read.
If this is the case, then where did that fingerprint data come from?
I'm assuming Android works much the same.
I was thinking the very same.
The app would gain TouchID authentication in some way, but being able to extract/copy the FingerPrint - and likely just the single digit - seems ridiculous.
That would point the finger - pun intended - at Apple and Google.
This is close enough. In reality, the application stores some encrypted data in the keychain and uses fingerprint or Face ID to decrypt it - of course you can just encrypt “yes” or “no”.
And possible responses are: “Error, phone doesn’t support finger print”, “Error, phone is not currently set up for finger print”, “Error, user denied finger print”, or the decoded data.
A deposit sent via BANS from the Royal Courts to HSBC, where I have had an account since 1967 (that's correct, 1967).
HSBC said nothing to me instead it opened up a new account in my name and refused to acknowledge the existence of this transfer. It was only transferred to me (as a person) after eight months during which time it ignored my communications, denied knowledge of it, etc. If it was for the assistance of persistent civil servants and a Whistle-Blower in the HSBC call centre in India**, I would be still bereft of this transfer!
E-banking might be profitable for the banks but until they accept errors can & do occur, I suggest you check account activity regularly.
**India is world fraud country N0.2, after Nigeria.
E-banking might be profitable for the banks but until they accept errors can & do occur, I suggest you check account activity regularly.
And read your letters. I normally ignore mine, but I did spot one a couple of years ago from TSB. They told me I had a bank account with them, which I don't. After a lot of to-ing and fro-ing, they closed the fraudulent account, and sent me a cheque for £0.67 as compensation. Seriously. And one of the girls on the phone eventually told me that you could open a bank account with anyone's identity if you had their mobile phone A/C data (but I have no idea what that means).
This comes down to the old issue of logging into a system as "Administrator" rather than a restricted user. We all know it's wrong, but it makes coding, testing and support soooo much easier.
Everyone is rushing their development, and we know security & testing only ever finds problems and causes delays :-(
Keyless cars, what a great idea - security will be in version 2.
There are some development activities that require root/admin but the practice should not be common and you should not be doing the changes on the live system.
So the only ones I've done recently are testing installers (in a VM), systemd services (setup via root but run as non root users), tweaking a touch screen driver for a new OS and hardware configuration. All done on test systems before migrating to production.
I've worked in companies that locked developers machines down as though they were front office machines, it became a nightmare to get anything done.
I'm currently leading the out-sourced development of a large package of work for a FTSE 100 company. At the company I work at we are using CI, automated analysis tools. A year in and my counterparts are still arguing with thier IT to get a CI setup with the similar tools for the target OS. To keep the project moving forward I've been supplying the OS pre-configured on the target systems for them with a complete build system .... They have taken to buying additional targets for them to do thier development off corporate network...
I suspect this is rather the opposite as it feels like the usual developers who only consider security as an afterthought and something that can be tacked on at a later date.
Such developers code applications assuming administrator level access to systems and resources and as any decent developer knows, tacking security on as an after thought only ever leads to poor security.
It's a lazy approach: security should start with "you have no access" followed by "you will be granted only the exact access you need", however a typical lazy developer will just plump for administrator level access from the outset because that means they don't have to consider access levels or security.
In this instance that doesn't cut it. IT, Infrastructure IT in particular, is responsible for the security. DevOps IS NOT getting credentials for sensitive data even if that need it. They will authenticate their users, retrieve rotating credentials from Secrets Manager (in the case of AWS) and use those credentials to access the data. AND ONLY the data they absolutely need.
The examples in the article are just laziness/incompetence. If you are a corporation using AWS and you don't fully understand AWS security best practices for GODS sake, ask AWS Support! They are more than happy to help you!
Great... so now we know that some banking apps are insecure... WHICH ONES?
Do I need to be concerned about it or not?
The nearest bank branch to me is a 10m round trip... I'm moving in a couple of weeks, and the nearest branch of my bank is going to be more like a 25m round trip. I do kinda need to use an app and I'm using it almost daily for something or another.
"In particular, developers should never reuse cloud shares meant for user data with internal corporate data, and should ensure all shares are appropriately locked down with permissions designed for the data being stored,"
Oh Maaan! Have you any idea how long that sort of stuff takes? You have to ask the guys in the other department to set things up and it can take hours... and they get all picky about exactly what you mean... and then when you need to change it it takes hours again.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
