#PEEK AT PASSWORDS SAVED ON CHROME PASSWORD#

This explains why MFA wasn’t set up on the account. So only we have to add a function to delete the cookies. The values are stored in the browser in the form of a cookie, so if the cookies are deleted then the password, as well as other values, also deleted. For this reason, they can’t be locked down with multifactor authentication the way user accounts can. Method 2: Another method by which we can use to remove the password, also other values from the form. Unlike standard user accounts, which are accessed by humans, service accounts are mostly reserved for automating machine-to-machine functions, such as performing data backups or antivirus scans every night at a particular time. The fault, instead, lies with the security people who designed the support system that was breached, specifically the way the breached service account was configured.Ī service account is a type of account that exists in a variety of operating systems and frameworks. However, it would be wrong for anyone to conclude that employee misconduct was the cause of the breach. The employee almost surely violated company policy, and it wouldn’t be surprising if the offense led to the employee’s firing. And if that prohibition wasn’t clear to some before, it should be now. Then, after compromising the personal account or device, the threat actor obtained the credentials needed to access the Okta account.Īccessing personal accounts at a company like Okta has long been known to be a huge no-no.

#PEEK AT PASSWORDS SAVED ON CHROME PASSWORD#

This means that when the employee logged in to the account on Chrome while it was authenticated to the personal Google account, the credentials got saved to that account, most likely through Chrome’s built-in password manager. The most likely avenue for exposure of this credential is the compromise of the employee’s personal Google account or personal device.” Advertisement “The username and password of the service account had been saved into the employee’s personal Google account. “During our investigation into suspicious use of this account, Okta Security identified that an employee had signed-in to their personal Google profile on the Chrome browser of their Okta-managed laptop,” Bradbury wrote. Once the threat actor had access, they could obtain administrative credentials for entering the Okta accounts belonging to 1Password, BeyondTrust, Cloudflare, and other Okta customers. In a post, Okta Chief Security Officer David Bradbury said that the most likely way the threat actor behind the attack gained access to parts of his company’s customer support system was by first compromising an employee’s personal device or personal Google account and, from there, obtaining the username and password for a special form of account, known as a service account, used for connecting to the support segment of the Okta network. While the postmortem emphasizes the transgressions of an employee logging in to a personal Google account on a work device, the biggest contributing factor was something the company understated: a badly configured service account. Identity and authentication management-provider Okta on Friday published an autopsy report on a recent breach that gave hackers administrative access to the Okta accounts of some of its customers.

Omar Marques/SOPA Images/LightRocket via Getty Images reader comments 176

Peek at passwords saved on chrome