Dunkin’ Suffering from Credential Stuffing Attacks

Attackers stealing your account to stuff themselves with Dunkin’ Donuts.

DD Perks

Dunkin’ is an American multinational coffee/donut company and quick service restaurant based in Massachusetts. Dunkin’ frequent consumers often sign up for their loyalty rewards program which is known as DD Perks. Upon registering for DD Perks, the user will be prompted for their full name, email, zip code, and mobile phone number. Once registered, the user is assigned with a 16 digit DD account number, a corresponding QR code. Users may then reload their account through purchasing a DD card in-store and inputting the value in the app or by adding a credit/debit card payment method. Every time the user makes a purchase and scan their QR code or provide their DD account number, they earn points which could be used to redeem free beverage. Additional to this users may also provide their birthday to get additional promotions. Although access to these accounts may seem worthless, there are underground or dark web portals where access to various rewards programs is sold for a few dollars.

Media Attention

On November 29th, 2018, USA Today’s has called out the publics’ attention to question Dunkin’ Donuts’ security. The post written by Mark Snider said that Dunkin’ has been notified of the data breach late October. The company did not suffer an internal breach, however, customer’s information was potentially accessed. The information depends on what data members of the loyalty club had in their DD Perks account, it may include customers’ account holder first and last names, email address, the 16-digit DD Perks account number and DD Perks QR code. In response to this breach, Dunkin’ sent letters to the compromised DD Perks account holders encouraging them to change their password and log back in.

Lawsuit

New York State has filed a lawsuit against Dunkin’ for allegedly failing to warn hundreds of thousands of customers affected in two separate cyber breaches in 2015 and 2018. Letitia James, the attorney general of the State of New York, claimed that despite the promise that Dunkin’ would protect their customer’s personal information, tens of thousands of dollars on customers’ stored value cards were stolen and over 19000 accounts are breached back in 2015. Furthermore, Dunkin failed to notify, protect, and implement appropriate safeguards, causing 300 000 more accounts to be compromised in 2018.

Attack

So what exactly caused these accounts to be compromised in the first place? and why did it take so long for Dunkin’ to implement an appropriate fix? The cyberattack that took place is known ad Credential Stuffing. Other than Dunkin’, many big companies have suffered from the same attack, to name a few, Sony, Yahoo, Dropbox, Reddit. Credential Stuffing⁴ is a subset of brute force attack, it is performed by automated injection of breached username/password pairs to fraudulently gain access to user accounts.

Anatomy of Attack

1. The attacker uses an automated bot to test the stolen credentials against many websites (for instance, social media sites or online marketplaces).
2. The attacker acquires spilled usernames and passwords from a website breach or password dumpsite.
3. The attacker uses an automated bot to test the stolen credentials against many websites (for instance, social media sites or online marketplaces).
4. Usage of the stolen credentials:

• The attacker drains stolen accounts of stored value, credit card numbers, and other personally identifiable information.
• The attacker may also use account information going forward for other nefarious purposes (for example, to send spam or create further transactions)
• The attacker sells the account on the dark web.

Possible Fixes

Multifactor Authentication

Multifactor authentication requires a user to provide multiple factors to authenticate into the system. Authentication meaning for the system to know that the user trying to access the system is indeed who they claim to be. There are four types of factors that could be used for authentication:

1. Information only is known to the user: Passwords, PINs and security questions.
2. Things only the user has: Hardware or software tokens, certificates, email, SMS and phone calls.
3. Physical attributes of the users: Fingerprints, facial recognition, iris scans, and handprint scans.
4. Location: Source IP ranges and geolocation.

Advantages

Multi-factor authentication (MFA) is by far the best defense against the majority of password-related attacks, with analysis by Microsoft suggesting that it would have stopped 99.9% of account compromises.

Disadvantages

Increase in management complexity for both administrators and end-users

Many less technical users may find it difficult to configure and use MFA. Additionally, there are several other common issues encountered:

• Types of MFA that require users to have specific hardware can introduce significant costs and administrative overheads. (fingerprint scanners etc.)
• Users may become locked out of their accounts if they lose or are unable to use their other factors.
• Many MFA solutions add external dependencies to systems, which can introduce security vulnerabilities or single points of failure.
• Processes implemented to allow users to bypass or reset MFA may be exploitable by attackers.
• Requiring MFA may prevent some users from accessing the application.

Secondary passwords, PIN or Security Question

An option to prevent credential stuffing attacks to require that a user uses a secondary password, pin or security question. In addition to the user inserting a username and password, the user would also have to provide either an additional password, a PIN or answer a security question that the user has previously chosen. This method of security can help prevent credential stuffing as the attacker would need to know additional information about the user to access the account as knowing a user’s email and password from another site is not enough. There are already sites and services that are using this model, for example, PayPal has implemented a PIN feature for their PayPal model applications. PayPal Point of Sale and other web pages PayPal uses (Paypal). A problem with using an additional PIN that PayPal mentions is either the user would select a generic PIN like 1234 or 1111 (Paypal), so implementing a secondary PIN feature on top of requiring a password would also require the person implementing the feature to account for generic PINs. But, this is similar to password constraints to require users to create strong passwords so for an organization like Dunkin’ Donuts it is not a hard feature to implement. If a PIN is not strong enough for an organization like Dunkin’ Donuts, then they can require a secondary password that would need to be entered along with the base password.

There is still a problem with this method that is also the reason why credential stuffing is possible. People have to manage a lot of accounts and passwords as according to the password manager CYCLONIS each person will have to manage at least 40 passwords (Cyclonis). Because of the number of passwords people need to remember people tend to reuse the same password across multiple accounts as it is easier to remember just one password for 40 different accounts than 40 unique passwords for each account. So if a user already has to remember a lot of passwords across multiple accounts, asking them to remember an additional PIN or password is a lot to ask for a user as PayPal says, “the more passwords you have to remember, the greater the risk you’ll forget some of them” (Paypal). For an account that is not as important to a user like the DD Perks account, having to remember an additional password or PIN on top of the base password is asking the user for a lot.

Then what about the third option in this method by requiring the user to answer a security question when logging in? This is an option that Dunkin Donut can implement in their DD Perks program accounts and implementing a security question is just as easy to implement as an additional password or PIN, but there are still fundamental problems with security questions. Questions are not configurable and may not apply to a user, a user can forget what answer they gave to a question, the attacker can be someone that already knows the user, the answer can be guessable if the security question has a small set of possible answers and finally the attacker and research the user and find information online to answer the security question correctly (Robert and Stuart). Especially in today’s day of social media finding information about a user is extremely easy and can make security questions insecure. Overall, though this method is very easy to implement and does fight the problem Dunkin’ Donuts faced with Credential Stuffing it still has its drawbacks.

CAPTCHA

Another option that an organization like Dunkin Donuts can use to fight Credential Stuffing is with using a CAPTCHA. CAPTCHA stands for Completely Automated Public Turing test to tell Computers and Humans Apart is a type of challenge and response protocol that is used to tell if a user is a human or not. Implementing a CAPTCHA used to be hard, but with services like reCAPTCHA implementing a CAPTCHA mechanism into a product is very simple. Also, reCAPTCHA was developed by Google for any organization to use so coming from a company like Google there is a level of security that is provided that would be expensive for Dunkin’ Donuts to implement themselves, especially for a product like the DD Perks program. The system that Google provides determines if a user is a human or not by looking at IP addresses and cookies that Google has seen elsewhere on the web and mouse movements before interacting with the CAPTCHA (Greenberg). If the reCAPTCHA system is not able to determine if the user logging in is a bot or not, then it will default back to the distorted text that has been used with CAPTCHAs in the past.

Though Google claims that reCAPTCHA is secure there is a case of a group of researchers at the University of Maryland that was able to break the reCAPTCHA system by using Google’s speech-to-text service with researchers claiming a 90 percent success rate of tricking the reCAPTCHA system. (Cole). There are other methods of breaking Google’s system, but so far they all require so form of machine learning or having the bot fake mouse movements to seem more like a human. This overall means that an attacker can trick the reCAPTCHA system into thinking that they are valid users, but it is hard and would greatly slow down the attack.

Compromised credential checking services (Google Password Checkup)

To expedite the process of identifying the breach, Dunkin’ could have used protocols that deal with compromised credentials such as HaveIBeenPwned (HIBP) and Google Password Checkup (GPC) as a daily security check for their IT department. Both services implement an algorithm called K-anonymity. How it works is that the user shares with the C3 server a prefix of the hash of their password or the hash of their username-password pair, then the server will send back a list of hashed passwords with the same prefix along with the number of times each password has been compromised. The user then searches in the list of hashed passwords to find if there is an exact match of the user’s hashed password if they do find it, it means that their password has been compromised and they will also know how many times it has been cracked. However, it is questionable that exposing the prefix of your hash to the server might compromise your password itself given an example where the C3 server has been compromised.

One of the papers that address such issues is Lucy Li’s, “Protocols for Checking Compromised Credentials”. In this paper, Li discussed and analyzed the technicality of modern C3 servers such as HIBP and GPC, her findings suggested that “in some contexts knowing the hash prefixes leads to a 12x increase in the efficacy of remote guessing attacks” (Li 1).

Additionally, Li also proposed two new protocols: Identifier-based bucketization (IDB) and Frequency-smoothing bucketization (FSB) in which she claimed that it will “provide stronger protection for users’ passwords” (Li 1). According to Li, how FSB assigns a password to many buckets relies on the probability and the frequency passwords are assigned to many buckets. Moreover, reducing the conditional probabilities of a given password can be done by replicating a password into multiple buckets effectively. Li claimed to do so in a way that makes the conditional probabilities of popular passwords similar to those of unpopular passwords to make it harder for the attacker to guess the correct password. However, Li mentioned that FSB only effective for non-uniform credential distributions, e.g., password distribution(Li 7). Therefore, FSB cannot be used to build a username-password C3 service, which we’ll see later on how it makes sense to compare FSB protocols with that of HIBP, rather than that of GCP since it uses username-password C3 service. Li described IDB as a new C3 protocol that uses HPB style bucketing, but based only on the username which is a user-name password C3 protocol, a modified version of GCP. IDB differs from GCP in how it uses hash-prefix of username instead of the hash-prefix of username-password combination as a bucket identifier. Moreover, she also explained that the bucket identifier is computed completely independently of the password (assuming the username is independent of the password). Therefore, the attacker gets no additional

advantage by knowing the bucket identifier (Li 7). However, Li also addressed the downside of IDB by stating that “Though IDB reveals nothing about the password, learning the username becomes easier (compared to GPC) an attacker can narrow down the potential user’s attacker seeing the bucket identifier. While this can be concerning for user’s privacy, we believe the benefit of not revealing anything about the user’s password outweighs the risk. Unfortunately, IDB does not work for the password-only C3 seeing because it requires that the server store username-password pairs”(Li 7).

Moving on to Li’s empirical analysis, figure 8 represents a resulting table from simulating an attack strategy between Hash-Prefix-Based (HPB), which is HIBP uses of bucketization, and FSB which is Li’s new protocol. The table suggests that the security loss from using HPB is large, especially for previously uncompromised users. Accessibility to the l = 20-bit hash prefix, used by HIBP, allows an attacker to compromise 32.9% of previously uncompromised users in just one guess. In fewer than 103 guesses, that attacker can compromise more than 70% of the accounts (12x more than the baseline success rate with 103 guesses). Google Password Checkup (GPC) uses l = 16 for its username-password C3 service. Against GPC, an attacker only needs 10 guesses per account to compromise 33% of accounts. Reducing the prefix length l can decrease the attacker’s advantage. However, that would also increase the bucket size. As we see for l = 12, the average bucket size is 105,642, so the bandwidth required to perform the credential check would be high. FSB resists guessing attacks much better than HPB does, this is because the conditional distribution of passwords given an FSB bucket identifier is nearly uniform, making it harder for an attacker to guess the correct password in the specified bucket.

Li’s paper did a great job of identifying and addressing the issue of modern C3 protocols (such as HIBP and GPC), specifically how these protocols do not provide a satisfying level of security. An attacker who obtains the query to such a C3 service and the username of the querying user can more easily guess the user’s password. She also went as far as giving more secure protocols (such as FSB and IDB) and proving how these protocols can do a better job at securing the C3 service against attackers. If Dunkin’ was to use the C3 services they should do so during the process of registration or password change process, to ensure that the new password is not present in a leak. In this setting, C3 is queried from a web server, and the client IP is potentially not revealed to the server. This is a safer setting that having the client querying the C3 server on their own, as their IP will potentially be exposed.

With this, Dunkin’ should not rely solely on modern C3 protocols alone but what they should do is try to increase the security of their user’s credentials by implementing some of the defenses mentioned above such as multifactor authentication and secondary passwords, rather than trying to rely on C3 services alone to deal with compromised credentials.

Cimpanu, Catalin. “Dunkin’ Donuts Accounts Compromised in Second Credential Stuffing Attack in Three Months.” ZDNet, ZDNet, 12 Feb. 2019, https://www.zdnet.com/article/dunkin-donuts-accounts-compromised-in-second-credential-stuffing-attack-in-three-months/.

Cole, Samantha. “Researchers Fool ReCAPTCHA With Google’s Own Speech-To-Text Service.” Vice, Vice, 4 Jan. 2019, www.vice.com/en_us/article/pa55z8/researchers-fool-recaptcha-with-googles-own-speech-to-text-service.

“Credential Stuffing.” OWASP, https://www.owasp.org/index.php/Credential_stuffing.

“Credential Stuffing Prevention.” Credential Stuffing Prevention · OWASP Cheat Sheet Series, https://cheatsheetseries.owasp.org/cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet.html.

Greenberg, Andy. “Google Can Now Tell You’re Not a Robot With Just One Click.” Wired, Conde Nast, 3 June 2017, www.wired.com/2014/12/google-one-click-recaptcha/.

Letitia James “Dunkin’ Complaint”,September 26, 2019, https://ag.ny.gov/sites/default/files/dunkin_complaint.pdf.

Li, Lucy et al. “Protocols for Checking Compromised Credentials.” CCS ’19 (2019).

“Multifactor Authentication.” Multifactor Authentication · OWASP Cheat Sheet Series, https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet.html.

“Password and PIN Security.” PayPal, www.paypal.com/us/webapps/mpp/security/secure-passwords.

“Password Security Report: 83% of Users Surveyed Use the Same Password for Multiple Sites.” Cyclonis, 16 July 2018, www.cyclonis.com/report-83-percent-users-surveyed-use-same-password-multiple-sites/.

Reeder, Robert W., and Stuart Schechter. “When the Password Doesn’t Work.” When the Password Doesn’t Work: Secondary Authentication for Websites — IEEE Journals & Magazine, ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=5696724.

Snider, Mike. “Dunkin’ Donuts Says Some DD Perks Members’ Accounts May Have Been Hit by Data Breach.” USA Today, Gannett Satellite Information Network, 29 Nov. 2018, https://www.usatoday.com/story/money/business/2018/11/29/dunkin-donuts-says-some-dd-perks-accounts-hit-data-breach/2152176002/.