Old Unwanted Internet Accounts are a Pain

[anorlunda]

My password manager (Lastpass) just reminded me that I have more than 100 accounts that are "old", meaning that I have not used them for a year or more. For example, in the years that I lived on a boat, I bought from BoatUS almost every week, and I received substantial cash back rewards as an incentive for being a member. But things change, and I haven't used BoatUS since 2017.

What are the risks?

• They might have credit card info or other personal info. The longer it sits there, the more exposure there it for it to be stolen. (My bank forces me to change credit card numbers once a year. That causes its own problems because the change breaks all the bill autopay arrangements I set up, and if I miss one, I get nasty letters saying that my payments are late.)
• They might have passwords re-used on other sites. (Fortunately, Lastpass detects reused passwords and it reminds me of that separately.)

I could visit those site and review the information, and perhaps change the passwords, and seed them with false personal info. But that's a lot of work. And I would need to redo that security review every year unless I kept detailed records on the security status of all my old accounts. That would be a waste of time for unwanted accounts. It would be better to just delete them.

After trying to delete my accounts on several sites, I realize that account deletion is not a supported feature on most web sites. (Even PF is the same. You can send and email to @Greg Bernhardt, but there is no button to click to permanently delete an account. PF has a good reason, since the archive of past posts is important.) Commercial sites do not have a good reason to keep my personal info and passwords after I stop doing business with them.

I think an account delete function should be standard on most web sites. We can't realistically force that via government regulation. It would have to become an industry best practice promulgated by trade associations.

 

[DavidSnider]

I've always thought some sort of personal info brokering service would be a good idea. These couldn't really prevent leaks if you have to ship something, but you can at least show some good faith that you respect the customer's wishes by having your company use such services.

There should be a sensible way to balance this and not have it be used for bad things like laundering.

 

[jedishrfu]

Sadly, while you may feel the companies have no need of your data after you no longer do business with them, you would be wrong as they market what they know about you to affiliated companies and so your data has value to them.

I do believe there should be an acct delete feature somewhere but also realize that should you get hacked the hacker may mess things up by deleting your acct. There was that one notable case with the security journalist MAtt Honan where hackers broke in.

In the space of one hour, my entire digital life was destroyed. First my Google account was taken over, then deleted. Next my Twitter account was compromised, and used as a platform to broadcast racist and homophobic messages. And worst of all, my AppleID account was broken into, and my hackers used it to remotely erase all of the data on my iPhone, iPad, and MacBook.

https://www.wired.com/2012/08/apple-amazon-mat-honan-hacking/

 

[Vanadium 50]

I lived on a boat

I "liked" that part.

 

[jedishrfu]

Cueing the theme from Gilligans Isle

 

[MikeeMiracle]

I think there are two parts here to consider:

1) Acount Deletion.
2) Data Erasure.

Deleting your account is straight forward, it's a basically just a "front door" into the data held by companies which can be locked / removed to prevent access using your account. The data behind it though is likely held in various databases, some with interdependancies with each others and trying to track down every last bit of "your data" on any system is no trivial task let alone removing it all.

On top of this even if it wuld be removed from "current systems," there are data backups to consider. Thre is no reasonable way to remove data from a backup without restoring the system to an old state when the backup was taken, removing just "your data" and re-backing it up again. This is just not practical for each bit of data removal from each system.

Unfortunately once your data is out there, it's likely out there for a long time until those backups are no longer required and over-written.

 

[anorlunda]

Unfortunately once your data is out there, it's likely out there for a long time until those backups are no longer required and over-written.

I agree. But there is one additional risk associated with old but active accounts. That is a hacker could use the account to order stuff to be shipped to him with the bill coming to me.

 

[DavidSnider]

if you’re primarily concerned with people ordering on your behalf most Credit card companies have proxy cards you can activate / deactivate at your will.

 

[etotheipi]

By the way, you can check for online accounts of yours that have been involved in data breaches here:
https://haveibeenpwned.com/
Useful site, you can also sign up to be notified whenever a new breach occurs.

 

[jtbell]

Cueing the theme from Gilligans Isle

But they were actually on the boat only for that three-hour cruise. Or part of it, anyway.

 

[jedishrfu]

But they were actually on the boat only for that three-hour cruise. Or part of it, anyway.

What could go wrong? :-) Murphy acts in mysterious ways to bring a great tv show.

 

[harborsparrow]

This won't fix the past--but for the present and future, I recommend you pick a couple of payment platforms (I use Google, Amazon and Paypal) and stick with only those. Any website demanding a payment from me MUST use one of those platforms, because I refuse to give my credit card info to small, third-party websites whose data security policies are unknown.

I do know that Paypal, Google and Amazon put HUGE amounts of effort into keeping customer information locked down.

I adopted this policy after my credit card was stolen online one year (it was actually after a purchase at Walmart--I knew it was Walmart--reported to police, Walmart denied it, then after a year Walmart was "outed" and they had continued to allow millions of customers to have their credit information stolen). After that, I got serious.

I have two emails--a Yahoo! account that I use for casual logons that I don't really want, and my Gmail account for logons I *do* want. And no payments directly by credit card, ever--only through one of the three payment services.

Yes, this has meant that, occasionally, I will not give to a GoFundMe or local non-profit. I sometimes contact them and try to explain that they need to accept one of the payment services to get a donation from me, and that the reason is security. They sometimes respond by adding, say, Paypal.

Anyway, I do cancel old unused accounts when I can, but as you noted, it's often more trouble than it's worth, sometimes requiring a call-in that can take a long time on hold.

 

[anorlunda]

I do know that Paypal, Google and Amazon put HUGE amounts of effort into keeping customer information locked down.

That is an excellent point that I never considered before. I may rethink my own habits.

But that same dichotomy also exists with offline transactions, such as at a store. These various e-pay systems that let you wave your phone at the register. They may have the potential to be more secure than use of a credit or debit card. But potentially more secure is not the same as actually more secure.

As consumers, we don't have the ability to do a security audit on our service providers, so it all comes down to trust. There is some validity to trusting famous names like Paypal, Google, Amazon, Apple, because if they are careless, it would make headlines in the news. But Visa and Mastercard are also famous names, and credit cards indemnify us from loss due to fraud. Their customer service phone numbers become part of the security, because I can call and dispute a charge.

I would like to see an article from a trusted expert like Bruce Schneier comparing the security of e-pay methods with traditional cards, both for online and offline transactions.

 

[Wrichik Basu]

And no payments directly by credit card, ever--only through one of the three payment services.

Here in India, whenever we pay using credit card directly, we have to put two numbers that the payment gateway does not (or should not) store — the CVV and an OTP. The CVV is a three digit number comes with the card and cannot be changed; it expires when the card expires. The gateway may save the card details like card number, expiry date, etc. but not the CVV. Once it is entered, we are taken to our bank's website where we have to put in the OTP that is sent to our registered mobile number. This concludes the transaction. Even if I consider the case where a keylogger steals the CVV, they will not be able to make a purchase unless they get the OTP.

Only two gateways do not follow this process — Paypal and Google. We generally do not use Google; if we do, it is mainly for purchases on Google Play, and we remove the card soon after the purchase is complete.

 

[harborsparrow]

...Visa and Mastercard are also famous names, and credit cards indemnify us from loss due to fraud. Their customer service phone numbers become part of the security, because I can call and dispute a charge.

The older wisdom was that credit cards do provide legal protection in case you need a refund. However, most places now (or so I have found) are pretty good about giving refunds if needed, and so unless it's a very large transaction, I stick with the payment services.

The point is, the unbelievable hassle one gets from having one's credit card stolen is terrible. And then, you have to worry for years afterwards about your entire identity being hi-jacked. THAT was the worry that changed my habits away from using a credit card in lots of places.

 

[Nick Levinson]

Where it's supported, I delete my card details after I finish a transaction. I'd rather re-enter the details whenever needed. One vendor deletes automatically, after a period to cover refunds and the like. Some don’t offer an option to delete and I wish they did.

I do not reuse passwords. If I decide to be lazy for a website that requires that I replace an expired password on their system and the password is already especially long, I’ll make a small change, because the small change can cascade into a big change in the encrypted form.

I do not use a password storage system in which a single password is a point of vulnerability, because if someone cracks it, they can get all of the other passwords.

Using false information in one’s identity or biography may violate terms. Sometimes, that has a sanction.

Security Q&As are an annoyance. I can't be sure that some database out there doesn't have my first pet's name (which, by the way, I forgot). For Q&As, I give fictional answers, so that something like "what's your sister's name?" is answered with something like "742748-fictional-6592647". Then they can sell my sister's name and I told them it's fictional so that should eliminate any issue with my giving false info. If I can create the question, it might be something like "why do elephants go spelunking on Tuesdays?", answered as "37 frying pans per twig". But Q&A systems are a serious vulnerability and I think one website I use dropped the system.

I don’t think most privacy policies are the least bit binding, so I don’t bother reading most of them or relying on privacy. My own websites are explicit about not giving privacy.

Terms are binding and I read them. I have sometimes refused to have a relationship with a website specifically because of the terms.

Account deletion should be an option. I think some websites decline to offer it because they hope you'll reactivate yours and because the statistic of humongous numbers of accounts increases the site's value for advertising and for sale of the website.

Free email accounts are generally deleted after a period of not using your login (perhaps a few months or a year), then perhaps reopened some months later but with a new password not disclosed to the original holder, then closed again for good; the reopening is to use the address as a spam honeypot, because your friends et al. presumably are not using that address anymore.

Historical record preservation is possible even with an account being closed by a website; all they have to do is disable your password, which one site did to me along with changing my username when I insisted on closing my account (that was good enough for me). They could, for example, store the data under the username but not allow any password to work except by an admin.

One site, when I discovered that not only am I responsible for whatever is done under my login (I knew that before and accepted that) but that they transmit my password in plaintext over the Internet, said it's illegal for them to close an account. I suspect their own customer service representative (reached via the CEO) was a lawyer who had a more helpful view of the law.

Another place suggested they don't know how to close an account. I reminded them it's generally done by deleting a row from a database table (a more sophisticated way is by adding a field for disabling the account even with a password so only the IT staff can enable it again) and they might have manuals to tell them how. But also I suggested they could send me all of their servers, mirrors, and backups so I could do it and then I would return everything for a fee to be negotiated when I'm done; that inspired them to close the account without my help.

 

[Tom.G]

...I would return everything for a fee to be negotiated when I'm done;...

Plus shipping I presume.

 

[DaveC426913]

But things change, and I haven't used BoatUS since 2017.

You have this whole thing backwards.

The best way to remedy your problem is to get another boat.

 

[harborsparrow]

There is a new twist to this topic--keyloggers. Because executable javascript library files are so ubiquitous, keyloggers that log every key you enter are more and more common. And now, even stylesheet files can contain executable code (thus, a keylogger) and this has been demonstrated in at least one case. Thus, entering a credit card over the web becomes more perilous every day.

And I have become more serious about not typing my credit card in on any website except the big 3, which already have mine.

 

[pbuk]

There is a new twist to this topic--keyloggers.

Keyloggers are hardly new.

Because executable javascript library files are so ubiquitous, keyloggers that log every key you enter are more and more common.

Do you have any evidence for this?

Unless it is exploiting some other vulnerability, javascript can only run on the web page that includes it so you can protect yourself against a javascript or CSS keylogger in the same way as you can protect yourself against any other web-based threat: don't visit sites you don't trust.

If you are referring to the potential introduction of malicious code into a website through package dependency hijacking then this IS definitely a concern for developers, and there is at least one example of a successful exploit (Copay, a BitCoin app), however although an npm package hijack could potentially result in a vulnerability to one or more websites collecting sensitive data I am not aware of this actually happening.

 

[harborsparrow]

Yes through packages...here is a recent example, admittedly not yet found in the wild:

https://www.zdnet.com/article/hackers-hide-web-skimmer-inside-a-websites-css-files/

 

[sysprog]

It's easy enough to monitor keystrokes when a user visits your page $-$ in this following example, whatever else the user may type, if the uninterrupted sequence 'physics' is entered, the browser will go to PF, just as if the user had clicked on a link $-$

(I used a screen shot because XenForo wouldn't allow the code even inside ubb code tags $-$ not even for Preview $-$ I got hundreds of lines of scolding in the browser console $-$ )

 

[pbuk]

Yes through packages...here is a recent example, admittedly not yet found in the wild:

https://www.zdnet.com/article/hackers-hide-web-skimmer-inside-a-websites-css-files/

Nothing in there about package hijack, it reports that the attackers simply gained access to the servers:

Web skimmer gangs gain access to a store and then modify its CSS and JavaScript files with malicious code.

 

[harborsparrow]

Well, packages are Javascript files. I like the term "package dependency hijacking", good jargon!

The point is, web security is complicated and not all the tools help with it, and so for an average programmer without special training, it would be possible for a website to be compromised in order to install a keylogger. It's a bad world out there.

Whether the keylogger actually runs in the browser or on the server, it is quite possible for one to be there, I fear. Better to do as little typing in of financial information as possible, IMHO.

 

[pbuk]

Well, packages are Javascript files. I like the term "package dependency hijacking", good jargon!

Dependency hijacking (also called package or repository hijacking) is a specific thing which is completely unrelated to the quoted article. I only brought it up because you referred to 'executable javascript library files' which is a phrase that doesn't mean anything to me and so I was trying to clarify the context.

The point is, web security is complicated and not all the tools help with it, and so for an average programmer without special training, it would be possible for a website to be compromised in order to install a keylogger. It's a bad world out there.

Yes, absolutely, creating a secure website requires specialist knowledge.

 

[harborsparrow]

Most web pages these days have Javascript which executes within the browser (and likely also communicates with the server). A keystroke logger would require that the server be compromised (which happens plenty).

Sometimes the Javascript is written by the webpage creator, but sometimes also it is library "packages" being sucked in.

I assumed you were talking about a third party "package" that has been compromised and then gets used on many servers--like recently happened to the government. That is one possibly vulnerability, as are UI Javascript library files, or even programmer created javascript files. All are potentially vulnerable, and I believe that the average programmer uses them with hardly a look at what they contain.

 

[sysprog]

you referred to 'executable javascript library files' which is a phrase that doesn't mean anything to me

There are packages that fill that bill $-$ perhaps @harborsparrow had something like jquery or modernizr or maybe JSON in mind $-$

from https://www.w3schools.com/js/js_json_intro.asp:

JSON - Introduction

JSON: JavaScript Object Notation.
JSON is a syntax for storing and exchanging data.
JSON is text, written with JavaScript object notation.

Exchanging Data
When exchanging data between a browser and a server, the data can only be text.

JSON is text, and we can convert any JavaScript object into JSON, and send JSON to the server.

We can also convert any JSON received from the server into JavaScript objects.

This way we can work with the data as JavaScript objects, with no complicated parsing and translations.​

 

[sysprog]

All are potentially vulnerable, and I believe that the average programmer uses them with hardly a look at what they contain.

 

[pbuk]

I assumed you were talking about a third party "package" that has been compromised and then gets used on many servers

Well I was trying to work out what you were talking about when you said...

Because executable javascript library files are so ubiquitous, keyloggers that log every key you enter are more and more common.

...because it wasn't clear, and you still haven't provided any evidence for the second part of that sentence.

--like recently happened to the government.

Which government used a compromised dependency on many servers?

That is one possibly vulnerability, as are UI Javascript library files, or even programmer created javascript files. All are potentially vulnerable, and I believe that the average programmer uses them with hardly a look at what they contain.

Yes, it is the very nature of software dependencies that application programmers, er, depend on them. Each dependency ecosystem includes various mitigations against such vulnerabilities and anyone developing or deploying applications which deal with sensitive data should be aware of these mitigations and their limitations.

 

[sysprog]

Well I was trying to work out what you were talking about when you said...

Because executable javascript library files are so ubiquitous, keyloggers that log every key you enter are more and more common.

...because it wasn't clear, and you still haven't provided any evidence for the second part of that sentence.

That knowledge is so common among programmers that it might seem unnecessary to cite examples to a fellow programmer $-$ nevertheless, the following is from:

https://www.mitre.org/about/our-history#node-104
$\Updownarrow$
https://attack.mitre.org/techniques/T1056/001/

Procedure Examples

ADVSTORESHELL can perform keylogging.[3][4]

Agent Tesla can log keystrokes on the victim’s machine.[5][6][7][8]

APT28 has used tools to perform keylogging.[9][10]

APT3 has used a keylogging tool that records keystrokes in encrypted files.[11]

APT32 has abused the PasswordChangeNotify to monitor for and capture account password changes.[12]

APT38 used a Trojan called KEYLIME to capture keystrokes from the victim’s machine.[13]

APT39 has used tools for capturing keystrokes.[14]

APT41 used a keylogger called GEARSHIFT on a target system.[15]

Astaroth logs keystrokes from the victim's machine.[16]

One of Attor's plugins can collect user credentials via capturing keystrokes and can capture keystrokes pressed within the window of the injected process.[17]

BabyShark has a PowerShell-based remote administration ability that can implement a PowerShell or C# based keylogger.[18]

When it first starts, BADNEWS spawns a new thread to log keystrokes.[19][20][21]

BadPatch has a keylogging capability.[22]

Bandook contains keylogging capabilities[23]

BISCUIT can capture keystrokes.[24]

BlackEnergy has run a keylogger plug-in on a victim.[25]

Cadelspy has the ability to log keystrokes on the compromised host.[26]

Carbanak logs key strokes for configured processes and sends them back to the C2 server.[27][28]

Cardinal RAT can log keystrokes.[29]

Catchamas collects keystrokes from the victim’s machine.[30]

CHOPSTICK is capable of performing keylogging.[31][3][10]

Cobalt Strike can track key presses with a keylogger module.[32]

Cobian RAT has a feature to perform keylogging on the victim’s machine.[33]

CosmicDuke uses a keylogger.[34]

DarkComet has a keylogging capability.[35]

Darkhotel has used a keylogger.[36]

Daserf can log keystrokes.[37][38]

Derusbi is capable of logging keystrokes.[39]

DOGCALL is capable of logging keystrokes.[40][41]

Duqu can track key presses with a keylogger module.[42]

$\dots$You can go to the https://attack.mitre.org/techniques/T1056/001/ link and see the whole list, complete with 130 references . . .

The https://attack.mitre.org site has a great set of resources.

 

[sysprog]

Which government used a compromised dependency on many servers?

Presumably any and all that used jQuery, either directly or by using something that uses it, e.g. AJAX $-$ probably every national government, and in the US at least, all or almost all state, county, and city governments have had some exposure in this regard.

From
Thou Shalt Not Depend on Me: Analysing the Use of Outdated JavaScript Libraries on the Web
Tobias Lauinger, Abdelberi Chaabane, Sajjad Arshad, William Robertson, Christo Wilson and Engin Kirda Northeastern University {toby, 3abdou, arshad, wkr, cbw, ek}@ccs.neu.edu

Permission to freely reproduce all or part of this paper for noncommercial purposes is granted provided that copies bear this notice and the full citation on the first page. Reproduction for commercial purposes is strictly prohibited without the prior written consent of the Internet Society, the first-named author (for reproduction of an entire paper only), and the author’s employer if the paper was prepared within the scope of employment. NDSS ’17, 26 February - 1 March 2017, San Diego, CA, USA Copyright 2017 Internet Society, ISBN 1-1891562-46-0 https://doi.org/10.14722/ndss.2017.23414​

:​

Yes, it is the very nature of software dependencies that application programmers, er, depend on them.

That seems facetious to me. The term 'software dependencies', as you undoubtedly well know, refers to the dependencies of higher-level or same-level software on same-level or lower-level software performing requested functions $-$ the term is only extensionally referential to anything that programmers depend on $-$ sometimes programmers are prevailed upon to deliver functionalities on a scale and schedule that necessitates incurring sotware dependencies that the programmer is not well-positioned to adequately vet.

Each dependency ecosystem includes various mitigations against such vulnerabilities and anyone developing or deploying applications which deal with sensitive data should be aware of these mitigations and their limitations.

Clearly just being aware isn't enough $-$ when the authority, the ability, and the accountability are not co-located, a scenario such that a boss mandates something that the marketers have already promised, the programmer adjures regarding the risks, then at the insistence of the boss, implements it hastily, and when something goes wrong, everyone who is potentially on the hook looks around for someone to blame $-$ it's easy enough to blame e.g. jQuery, AJAX, modernizr, node.js, JSON, etc. $-$ everyone is using those libraries, the argument goes, so no individual may legitimately be regarded as the culprit when one of the libraries introduces a vulnerability.

 

[pbuk]

None of the attackers listed in #30 are javascript based - that is the wrong section of Mitre, you should be looking at https://attack.mitre.org/techniques/T1059/007/.

I have looked at some of the references on the T1059.007 page and all those I have looked at the attack vector is either XSS (cross-site scripting) or server compromise (for a more extensive list of javascript vulnerabilities you can search Mitre's CVE database). None I have looked at is dependency compromise: as I mentioned above the only javascript dependency compromise exploit I have seen reported is the event-stream/copay vulnerability listed on Mitre here and described in reasonable detail comprehensible to non-experts here. The product that was compromised was the mobile phone app Copay, not a web site, and the exploit was not a keylogger.

 

[pbuk]

Presumably any and all that used jQuery, either directly or by using something that uses it

Now you are talking about something else, jQuery has never been hijacked, and no version of jQuery has a vulnerability that can be exploited directly so any site using it is exposed.

 

[sysprog]

None of the attackers listed in #30 are javascript based - that is the wrong section of Mitre, you should be looking at https://attack.mitre.org/techniques/T1059/007/.

You referred to "evidence for the second part of that sentence", which was "keyloggers that log every key you enter are more and more common" $-$ it was not regarding the first part of @harborsparrow 's sentence, which made reference to JavaScript libraries as a source of keyloggers, that I was responding; it was regarding only the second part.

I have looked at some of the references on the T1059.007 page and all those I have looked at the attack vector is either XSS (cross-site scripting) or server compromise (for a more extensive list of javascript vulnerabilities you can search Mitre's CVE database).

I agree with you there $-$ there have been numerous"XSS (cross-site scripting)'' attacks wherein the scripting language was JavaScript, especially when jQuery (subsequent to Release 1.0.3 $-$ October, 2006, and prior to Release 3.5.1 $-$ May 4, 2020) was in use.

None I have looked at is dependency compromise: as I mentioned above the only javascript dependency compromise exploit I have seen reported is the event-stream/copay vulnerability listed on Mitre here and described in reasonable detail comprehensible to non-experts here.

I think that this qualifies as a "dependency compromise" $-$ from https://snyk.io/vuln/SNYK-JS-JQUERY-565129:

Cross-site Scripting (XSS)
Affecting jquery package, versions >=1.0.3 <3.5.0
Overview
jquery is a package that makes things like HTML document traversal and manipulation, event handling, animation, and Ajax much simpler with an easy-to-use API that works across a multitude of browsers.

Affected versions of this package are vulnerable to Cross-site Scripting (XSS) Passing HTML containing <option> elements from untrusted sources - even after sanitizing it - to one of jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may execute untrusted code.​

The product that was compromised was the mobile phone app Copay, not a web site, and the exploit was not a keylogger.

Some jQuery vulnerabilities have been XSS-based, and have not been specifically keyloggers, although the 'untrusted code' introduced by XSS attacks could include keyloggers within a browser page $-$ from https://nvd.nist.gov/vuln/detail/CVE-2020-11023:

In jQuery versions greater than or equal to 1.0.3 and before 3.5.0, passing HTML containing <option> elements from untrusted sources - even after sanitizing it - to one of jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may execute untrusted code. This problem is patched in jQuery 3.5.0.​

$-$ which didn't come out until May of last year $-$ the problem has existed since no later than October of 2006 $-$ so it was out there for over 2 decades and people just kept chuntering along all the while $\dots$

 

[sysprog]

Now you are talking about something else, jQuery has never been hijacked, and no version of jQuery has a vulnerability that can be exploited directly so any site using it is exposed.

You asked "Which government used a compromised dependency on many servers?" $-$ although something that is 'hijacked' is 'compromised', not everything that is 'compromised' is 'hijacked' $-$ I responded to the question that you asked; not "about something else".

no version of jQuery has a vulnerability that can be exploited directly so any site using it is exposed

Even if that's true, it's not the same thing as being a 'compromised dependency' $-$ a site using jQuery 2.0, which is provably a compromised dependency, doesn't necessarily thereby incur an exposure; however, a programmer who uses a compromised dependency, without knowing precisely how to avoid the associated vulnerability, and how to ensure that others who might modify the code are adequately unlikely to fail to also avoid it, and acting accordingly, may be taking excessive risk.