Not just hacked
Not just hacked, but left compromised for, what, 11 months?
Jeebus.
They will have taken absolutely everything they wanted, and/or absolutely everything that was available.
News aggregation app Flipboard has publicly confessed that hackers accessed personal data about its members. Although the biz did not say how many customers had been affected, the app has been installed more than half a billion times, according to its Google Play Store listing. The databases that got away, according to a …
Over half a billion installs
Perhaps, but if it's the app I'm thinking of it came prei-nstalled on my last phone and one of the first things I did was disable it because it was annoying. I suspect there may be many cases like me, so installed numbers doesn't necessarily equate to registered users.
"it came prei-nstalled on my last phone and one of the first things I did was disable it "
So what? I note that you didn't say you uninstalled it.
*You* may not be able to make use of the "disabled" app but why do you think the functionality it provided (and the hackability?) won't be available to other apps on the same phone?
Just askin for a friend...
The app could be disabled, but I struggled to fin d away to install it - the phone manufacturer seemed to have baked it in to their Android installation
I never created a user account or anything, so I don't see a danger of any apps using it in the background and doing anything that would cause any risk with my identity seeing as I never provided one to the app in the first place
"...by default."
This is the sort of thing that ticks me off an an infosec person. Normally, I'd say no big loss for a compromised account on a news aggregator--assuming all that was stored was username, password, and subscribed lists. But, if that thing ties back to a phone app that would risk compromising the entire phone, then time to wipe the entire phone.
Let's see. In April of 2010, they move from SHA-1 to bcrypt as their password hash. Thier options follow:
1) Add a bit to their user table, indicating old vs new. When a password is updated, keep the same system.
2) Add a bit to their user table, indicating old vs new. When a password is updated, store in new.
3) Add a bit to their user table, indicating old vs new. When an old user logs in, force a password update, and store new.
4) Add a bit to their user table, indicating old vs new. When an old user logs in, use SHA-1 and then bcrypt.
These guys operating in the EU? GDPR anyone?
or
Add no bit to user table, but expand the password field so that it is large enough to store a bcrypt hash.
Then, on logon validation, look at the length of the stored hash. If length != 20 ** then assume bcrypt and proceed accordingly, but if length == 20 then assume SHA1, validate against the stored hash, and if it passes updated the stored hash with the bcrypted version of the same value. After a REASONABLE period of time expire and wipe any account still having an SHA1 hash in the database and if the user does comes back make them go through a password reset procedure to establish a new, secure password.
** or 40 if storing the hexidecimal string instead of the actual hash.