{
	"id": "fc6a903f-b872-4fba-9c58-7775cc27e187",
	"created_at": "2026-04-06T00:12:36.924429Z",
	"updated_at": "2026-04-10T03:24:29.17631Z",
	"deleted_at": null,
	"sha1_hash": "f9b4b20eca7ce5ffa6551864a2d97264af5e8eef",
	"title": "Password Managers: Under the Hood of Secrets Management",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 485422,
	"plain_text": "Password Managers: Under the Hood of Secrets Management\r\nArchived: 2026-04-05 19:13:26 UTC\r\nIntroduction: \r\nFirst and foremost, password managers are a good thing. All password managers we have examined add value to\r\nthe security posture of secrets management, and as Troy Hunt, an active security researcher once wrote,\r\n“Password managers don’t have to be perfect, they just have to be better than not having one” [5]. Aside from\r\nbeing an administrative tool to allow users to categorize and better manage their credentials, password managers\r\nguide users to avoid bad password practices such as using weak passwords, common passwords, generic\r\npasswords, and password reuse. \r\nThe tradeoff is that users’ credentials are then centrally stored and managed, typically protected by a single master\r\npassword to unlock a password manager data store. With the rising popularity of password manager use it is safe\r\nto assume that adversarial activity will target the growing user base of these password managers. Table 1, below,\r\noutlines the number of individual users and business entities for each of the password managers we examine in\r\nthis paper. \r\nPassword Manager  Users  Business Entities \r\n1Password  15,000,000 [6]  30,000 [6] \r\nDashlane  10,000,000 [7]  10,000 [7] \r\nKeePass  20,000,000 [8]  Unknown \r\nLastPass  16,500,000 [9]  43,000 [9] \r\nTable 1. Number of private users and business entities of 1Password (all versions), Dashlane, KeePass and\r\nLastPass. \r\nMotivation: \r\nWith the proliferation of online services, password use has gone from about 25 passwords per user in 2007 [10] to\r\n130 in 2015 and is projected to grow to 207 in 2020 [11]. This, combined with a userbase of 60 million across\r\npassword managers we examine in this paper, creates a target rich environment in which adversaries can carefully\r\ncraft methods to extract an increasingly growing and valuable trove of secrets and credentials. \r\nAn example in which a password manager appears to have been specifically targeted is an attack that led to the\r\nloss of 2578 units of Ethereum (ETH), a cryptocurrency valued at the time of 1.5 million USD. The attack was\r\ncarried out against a cryptocurrency trading assistant platform, Taylor [12]. Taylor issued a statement that\r\nindicated a device which was using 1Password for secrets management was compromised [13]. It remains unclear,\r\nhttps://www.ise.io/casestudies/password-manager-hacking/\r\nPage 1 of 18\n\nwhether the attacker found a security issue in 1Password itself or simply discovered the master password in some\r\nother way, or whether the compromise had nothing to do with password managers.\r\nGiven the combination of an increasing number of credentials held in password managers, the value of those\r\nsecrets and the emerging threats specifically targeting password managers it is important for us to examine the\r\nincreased risk a user or organization faces in terms of secrets exposure when using a password manager. Our\r\napproach for this was to survey popular password managers to determine common defenses they employ against\r\nsecrets exfiltration. We incorporate the best security features of each into a hypothetical, best possible password\r\nmanager, that provides a minimum set of guarantees outlined in the next section. Then we compare the password\r\nmanagers studied against those security guarantees. \r\nPassword Manager Security Guarantees: \r\nAll password managers studied work in the same basic way. Users enter or generate passwords in the software and\r\nadd any pertinent metadata (e.g., answers to security questions, and the site the password goes to). This\r\ninformation is encrypted and then decrypted only when it is needed for display, for passing to a browser add-on\r\nthat fills the password into a website, or for copying to the clipboard for use. \r\nThroughout this paper we will refer to password managers in three states of existence: not running, unlocked (and\r\nrunning), and locked (and running; this state assumes the password manager was previously unlocked). We\r\nassume that the user does not have additional layers of encryption such as full disk encryption or per process\r\nvirtualization. We define the three states below: \r\nNot Running \r\nWe define “not running” as a state where the password manager has previously been installed, configured, and\r\ninteracted with by the user to store secrets, but has not been launched since the last reboot or has been terminated\r\nby the user since it was last used. \r\nIn this “not running” state the password manager should guarantee: \r\nThere should be no data stored on disk that would offer an attacker leverage toward compromising the\r\ndatabase stored on disk (e.g. the master password or encryption key stored in a configuration file). \r\nEven if an attacker retrieves the password database from disk, it should be encrypted in such a way that an\r\nattacker cannot decrypt it without knowing the master password. \r\nThe encryption should be designed in such a way that, so long as the user did not use a trivial password,\r\nthe attacker cannot brute force guess the master password in a reasonable amount of time using commonly\r\navailable computing resources. \r\nRunning: Unlocked State \r\nWe define running in an “unlocked state” as cases where the password manager is running, and where the user has\r\ntyped in the master password in order to decrypt and access the stored passwords inside the manager. The user\r\nmay have displayed, copied to clipboard, or otherwise accessed some of the passwords in the password manager. \r\nIn this “running, unlocked state” the password manager should guarantee: \r\nhttps://www.ise.io/casestudies/password-manager-hacking/\r\nPage 2 of 18\n\nIt should not be possible to extract the master password from memory, either directly or in any form that\r\nallows the original master password to be recovered. \r\nFor those stored passwords that have not been displayed/copied/accessed by the user since the password\r\nmanager was unlocked, it should not be possible to extract those unencrypted passwords from memory. \r\nKnowing usability constraints that affect password managers, we concede that: \r\nIt may be possible to extract those passwords from memory that were displayed/copied/accessed in the\r\ncurrent unlocked session. \r\nIt may be possible to extract cryptographic information derived from the master password sufficient to\r\ndecrypt other stored passwords, but not the master password itself. \r\nRunning: Locked State \r\nWe define “in locked state” as cases where (1) the password manager was just launched but the user has not\r\nentered the master password yet, or (2) the user previously entered the master password and used the password\r\nmanager, but subsequently clicked the ‘Lock’ or ‘Log Out’ button. \r\nIn this “running, locked state” the password manager should guarantee: \r\nAll the security guarantees of a not-running password manager should apply to a password manager that is\r\nin the locked state. \r\nSince a locked password manager still exists as a process in virtual memory, this requires additional guarantees: \r\nIt should not be possible to extract the master password from memory, either directly or in any form that\r\nallows the original master password to be recovered. \r\nIt should not be possible to extract from memory any cryptographic information derived from the master\r\npassword that might allow passwords to be decrypted without knowing the master password. \r\nIt should not be possible to extract any unencrypted passwords from memory that are stored in the\r\npassword manager. \r\nIn addition to these explicit security guarantees, we expect password managers to incorporate additional hardening\r\nmeasures where possible, and to have these hardening measures enabled by default. For example, password\r\nmanagers should attempt to block software keystroke loggers from accessing the master password as it is typed,\r\nattempt to limit the exposure of unencrypted passwords left on the clipboard, and take reasonable steps to detect\r\nand block modification or patching of the password manager and its supporting libraries that might expose\r\npasswords. \r\nScope: \r\nIn this paper we will examine the inner workings as they relate to secrets retrieval and storage of 1Password,\r\nDashlane, KeePass and LastPass on the Windows 10 platform (Version 1803 Build 17134.345) using an Intel i7-\r\n7700HQ processor. We examine susceptibility of a password manager to secrets exfiltration via examination of the\r\npassword database on disk; memory forensics; and finally, keylogging, clipboard monitoring, and binary\r\nhttps://www.ise.io/casestudies/password-manager-hacking/\r\nPage 3 of 18\n\nmodification. Each password manager is examined in its default configuration after install with no advanced\r\nconfiguration steps performed. \r\nThe focus on our evaluation of password managers is limited to the Windows platform. Our findings can be\r\nextrapolated to password manager implementations in other operating systems to guide research to areas of\r\ninterest that are discussed in this paper. \r\nTarget Password Managers:\r\nThe following password managers with their corresponding versions were evaluated:\r\nProduct  Version \r\n1Password4 for Windows  4.6.2.626 \r\n1Password7 for Windows  7.2.576 \r\nDashlane for Windows  6.1843.0 \r\nKeePass Password Safe  2.40 \r\nLastPass for Applications  4.1.59 \r\nSecurity of Password Managers in the Non-Running State\r\nWe first consider the security of password managers when they are not running. We focus on the attack vector of\r\ncompromising passwords from disk. Unless password managers have severe vulnerabilities such as logging\r\npasswords to unencrypted log files or other egregious issues, the password managers’ defenses against the disk\r\nattack surface rest on the cryptography used to protect the password database. Here, we examine which algorithm\r\neach password manager uses to transform the master password into an encryption key, and whether the algorithm\r\nand number of iterations is severely lacking in its ability to resist contemporary cracking attacks.\r\nTable 2, below, outlines the key expansion algorithm type used and number of iterations in each password\r\nmanager’s default configuration. With regard to key expansion recommendations set by NIST [14]we found that\r\neach key expansion algorithm used in the password managers was acceptable and that the number of iterations\r\nadequate. We concluded that the password managers were secure against compromising passwords from disk as\r\nthe software is not running, and that brute forcing the encrypted password entries on disk would be\r\ncomputationally prohibitive, although not impossible if given enough computing resources. Given this, we moved\r\non to the attack surface of passwords stored in memory while the password managers are running.\r\nPassword Manager Key Expansion Algorithm Iterations\r\n1Password4 PBKDF2-SHA256 40,000 [15]\r\n1Password7 PBKDF2-SHA256 100,000 [16]\r\nDashlane Argon2 3 [17]\r\nhttps://www.ise.io/casestudies/password-manager-hacking/\r\nPage 4 of 18\n\nKeePass AES-KDF 60,000 [18]\r\nLastPass PBKDF2-SHA256 100,100 [19]\r\nTable 2. Each password managers default key expansion algorithm and number of iterations.\r\nSecurity of Password Managers in Running States\r\nWe expected and found that all password managers reviewed sufficiently protect the master password and\r\nindividual passwords while they are notrunning. The remaining bulk of our assessment of password managers in\r\nthe running state was focused on the effectiveness of the locked state and whether the unlocked state left the\r\nminimum possible amount of sensitive information in memory. The following sections outline violations of our\r\nproposed security guarantees of password managers in a running locked and unlocked state.\r\n1Password4 (Version: 4.6.2.626)\r\nWe assessed the security of 1Password4 while running and found reasonable protections against exposure of\r\nindividual passwords in the unlocked state; unfortunately, this was overshadowed by its handling of the master\r\npassword and several broken implementation details when transitioning from the unlocked to the locked state. On\r\nthe positive side, we found that as a user accesses different entries in 1Password4, the software is careful to clear\r\nthe previous unencrypted password from memory before loading another. This means that only one unencrypted\r\npassword can be in memory at once. On the negative side, the master password remains in memory when\r\nunlocked (albeit in obfuscated form) and the software fails to scrub the obfuscated password memory region\r\nsufficiently when transitioning from the unlocked to the locked state. We also found a bug where, under certain\r\nuser actions, the master password can be left in memory in cleartext even while locked.\r\nFailure to Scrub Obfuscated Master Password from Memory\r\nIt is possible to recover and deobfuscate the master password from 1Password4 since it is not scrubbed from\r\nmemory after placing the password manager in a locked state. Given a scenario where a user has unlocked\r\n1Password4 and then placed it back into a locked state, 1Password4 will prompt for the master password again as\r\nshown in Figure 1below. However, 1Password4 retains the master password in memory, although in an\r\nencoded/obfuscated format as shown in Figure 2.\r\nFigure 1. 1Password4 in a locked state awaiting master password input.\r\nhttps://www.ise.io/casestudies/password-manager-hacking/\r\nPage 5 of 18\n\nFigure 2. Encoded master password present in memory while 1Password4 is in a locked state.\r\nWe can use this information to intercept normal workflows in which 1Password4 calls\r\nRtlRunEncodeUnicodeString and RtlRunDecodeUnicodeString to obfuscate the master password to instead reveal\r\nthe already present, but encoded master password into cleartext (Figure 3).\r\nFigure 3. Master password revealed after the expected  RtlRunEncodeUnicodeString and\r\nRtlRunDecodeUnicodeString was reversed, thereby forcing 1Password4 to decode the encoded master password\r\nthat was not scrubbed from memory.\r\nCopying the Current Password Entry from Memory\r\nOnly entries that are actively being interacted with exist in memory as plaintext. Figure 4is an example of an entry\r\nin memory as its being interacted with. Once 1Password4 is locked, the memory region is deallocated . Note that\r\nthe deallocated region is not first scrubbed, however the Windows memory manager will zero out any freed pages\r\nof memory before making them available for re-allocation by the Windows memory manager.\r\nFigure 4. Password entry in memory during active interaction.\r\n1Password7 (Version: 7.2.576)\r\nAfter assessing the legacy 1Password4, we moved on to 1Password7, the current release. Surprisingly, we found\r\nthat it is less secure in the running state compared to 1Password4. 1Password7 decrypted all individual passwords\r\nin our test database as soon as it is unlocked and caches them in memory, unlike 1Password4 which kept only one\r\nentry at a time in memory. Compounding this, we found that 1Password7 scrubs neither the individual passwords,\r\nthe master password, nor the secret key (an extra field introduced in 1Password6 that combines with the master\r\nhttps://www.ise.io/casestudies/password-manager-hacking/\r\nPage 6 of 18\n\npassword to derive the encryption key) from memory when transitioning from unlocked to locked. This renders\r\nthe “lock” button ineffective; from the security standpoint, after unlocking and using 1Password7, the user must\r\nexit the software entirely in order to clear sensitive information from memory as locking should.\r\nIt appears 1Password may have rewritten their software to produce 1Password7 without implementing secure\r\nmemory management and secrets scrubbing workflows present in 1Password4 and abandoning the distinction\r\nbetween a ‘running unlocked’ and ‘running locked’ state in terms of secrets exposure. Interestingly, this is not the\r\ncase. Prior marketing material for  1Password claimed [20]to feature Intel SGX technology. This technology\r\nprotects secrets inside secure memory enclaves so that other processes and even higher privileged components\r\n(such as the kernel) cannot access them. Were SGX to be implemented correctly, 1Password7 would have been the\r\nmost secure password manager in our research by far. Unfortunately, SGX was only supported as a beta feature in\r\n1Password6 and early versions of 1Password7, and was dropped for later versions. This was only evident from\r\ngathering the details about it on a 1Password support forum [21].\r\nExposure of Cleartext Master Password, Secret Key and Entries in Memory\r\nAs stated before, all secrets are exposed by 1Password7 when in an unlocked and locked state. To demonstrate the\r\nseverity of this issue we created proof of concept code to read 1Password7’s memory address space to extract\r\nthese items. The proof of concept applications ran in the existing user context (which was an ordinary non-administrative user).\r\nShow below is 1Password7 in a locked state, Figure 5(having previously been unlocked but then again locked)\r\nawaiting password entry to unlock it.\r\nFigure 5. 1Password7 in a locked state, having previously been open and then locked.\r\nFigure 6 illustrates the automated retrieval of the master password.\r\nhttps://www.ise.io/casestudies/password-manager-hacking/\r\nPage 7 of 18\n\nFigure 6. Extracting the master password from a locked 1Password7 instance\r\nFigure 7 shows the extraction of the secret key that is needed along with the master password to unlock an\r\nencrypted database, and Figure 8shows the automated extraction of secret entries.\r\nFigure 7. Extracting the secret key from 1Password7 in a locked state.\r\nhttps://www.ise.io/casestudies/password-manager-hacking/\r\nPage 8 of 18\n\nFigure 8. Extracting password entries from a locked instance of 1Password7.\r\nThe memory “hygiene” of 1Password7 is so lacking, that it is possible for it to leak passwords from memory\r\nwithout an intentional attack at all. During our evaluation of 1Password7, we encountered a system stop error\r\n(kernel mode exception) on our Windows 10 workstation, from an unrelated hardware issue, that created a full\r\nmemory debug dump to disk. While examining this memory dump file, we came across our secrets that\r\n1Password7 held cleartext, in memory, in a locked state when the stop error occurred (Figure 9).\r\nFigure 9. Windows 10 crash dump file contained secrets 1Password7 held in memory in a locked state.\r\nFor all password managers that leave secrets in memory, this creates a threat model where secrets may be\r\nextracted in a non-running state as a by-product of system activity and/or crash/debug log files. Moreover, some\r\ncompanies have a policy to image workstations that have had malware encounters as part of the incident response\r\nprocedure. A user that happened to be running 1Password7 while this procedure was initiated should assume that\r\nall secrets have been compromis\r\nDashlane (Version: 6.1843.0)\r\nhttps://www.ise.io/casestudies/password-manager-hacking/\r\nPage 9 of 18\n\nIn our Dashlane evaluation, we noted workflows that indicate focus was placed on concealing secrets in memory\r\nto reduce their likelihood of extraction. Also, unique to Dashlane, was the usage of memory/string and GUI\r\nmanagement frameworks that prevented secrets from being passed around to various OS API’s that could expose\r\nthem to eavesdropping by trivial malware.\r\nSimilar to 1Password4, Dashlane exposes only the active entry a user is interacting with. So, at most, the last\r\nactive entry is exposed in memory while Dashlane is in an unlocked and locked state. However, once a user\r\nupdates any information in an entry, Dashlane exposes the entire database plaintext in memory and it remains\r\nthere even after Dashlane is logged out of or ‘locked’.\r\nExposure of Cleartext Entries in Memory\r\nPassword entries in Dashlane are stored in an XML object. Upon interacting with any entry this XML object\r\nbecomes exposed in cleartext and can be easily extracted in both locked and unlocked states. Figure 10, below, is\r\nan example of a portion of this XML data structure.\r\nFigure 10. Excerpt of a fully decrypted Dashlane XML password database in an unlocked and locked state.\r\nKnowing that this data structure exists in a locked state, we then created a proof of concept application to extract it\r\nfrom a locked instance of Dashlane. Figure 11, below, is a locked instance of Dashlane prompting for the master\r\npassword to unlock it.\r\nhttps://www.ise.io/casestudies/password-manager-hacking/\r\nPage 10 of 18\n\nFigure 11. Locked instance of Dashlane.\r\nIn this locked state, we then run our proof of concept to extract all stored secrets (Figure 12).\r\nFigure 12. Extracting secrets from a locked instance of Dashlane.\r\nHowever, even though we are able to extract secrets from a locked state of Dashlane, the memory region they\r\nreside in has been dereferenced and freed. So, over time portions of the XML data structure may be overwritten.\r\nThroughout our examination, we noticed that secrets may reside for a few minutes. In some instances, we have\r\nobserved them still resident in memory more than 24 hours.\r\nDashlane is also unique compared to the other password managers in our examination in that it does not allow you\r\nto exit the process via GUI components, such as clicking the close program [x] in the upper right or pressing the\r\nALT-F4 key combination. Doing so causes Dashlane to minimize into the task tray, leaving it susceptible to\r\nsecrets extraction for extended periods of time.\r\nKeePass (Version: 2.40)\r\nhttps://www.ise.io/casestudies/password-manager-hacking/\r\nPage 11 of 18\n\nUnlike the other password managers, KeePass is an open source project. Similar to 1Password4, KeePass decrypts\r\nentries as they are interacted with, however, they all remain in memory since they are not individually scrubbed\r\nafter each interaction. The master password is scrubbed from memory and not recoverable. However, while\r\nKeePass attempts to keep secrets secure by scrubbing them from memory, there are obviously errors in these\r\nworkflows as we have discovered that while even in a locked state, we were able to extract entries that had been\r\ninteracted with.\r\nKeePass claims to use several defenses in depth memory protection mechanisms as stated in an excerpt from their\r\nsite below (Figure 13). However, they acknowledge that these workflows may involve Windows OS API’s that\r\nmay make copies of various memory buffers which may not be exposed to KeePass for scrubbing.\r\nFigure 13. KeePass statement on memory protection.\r\nExposure of Cleartext Entries in Memory\r\nEntries that have been interacted with remain exposed in memory even after KeePass has been placed into a\r\nlocked state. Figure 14, below, is an example of a locked instance of KeePass prompting for the master password\r\nbefore it can be unlocked.\r\nFigure 14. Locked instance of KeePass.\r\nhttps://www.ise.io/casestudies/password-manager-hacking/\r\nPage 12 of 18\n\nSecrets are scattered in memory with no references. However, performing a simple strings dump from the process\r\nmemory of KeePass reveals a list of entries that have been interacted with (Figure 15).\r\nFigure 15. List of entries from a locked instance of KeePass.\r\nUsing the above information, we can then search for a username to an entry and locate its corresponding password\r\nfield entry, in the below image (Figure16) we locate the bitcoin private key which was stored in the password\r\nfield.\r\nFigure 16. Locating a bitcoin private key via its corresponding public key/username.\r\nThe above methodology can be used to extract any entries that have been interacted with before placing KeePass\r\ninto a locked state.\r\nLastPass (Version: 4.1.59)\r\nSimilar to 1Password4, LastPass obfuscates the master password as its being typed into the unlock field. Once the\r\ndecryption key has been derived from the master password, the master password is overwritten with the phrase\r\n“lastpass rocks” (Figure17).\r\nhttps://www.ise.io/casestudies/password-manager-hacking/\r\nPage 13 of 18\n\nFigure 17. Master password overwritten once the master password has been used in a PBKDF2 key expansion\r\nroutine.\r\nOnce LastPass enters an unlocked state, database entries are decrypted into memory only upon user interaction.\r\nHowever, these entries persist in memory even after LastPass has been placed back into a locked state.\r\nExposure of Cleartext Master Password and Entries in Memory\r\nDuring a workflow to derive the decryption key, the master password is leaked into a string buffer in memory and\r\nnever scrubbed, even when LastPass is placed into a locked state.\r\nThe below image, Figure 18, is an instance of LastPass in a locked state awaiting user entry of the master\r\npassword.\r\nFigure 18. Locked instance of LastPass.\r\nIn this locked state, we can recover the master password and any interacted with password entries with the same\r\nmethodology used in KeePass, in which a simple strings dump was performed on the active process.\r\nThe image below, Figure19, is an example of recovering the master password, in a locked state, which ironically is\r\nalways found within a few lines of ‘lastpass rocks’, the phrase used to conceal the master password in another\r\nhttps://www.ise.io/casestudies/password-manager-hacking/\r\nPage 14 of 18\n\nbuffer.\r\nFigure 19. Master password in cleartext (underlined red) typically within a few lines of ‘lastpass rocks’.\r\nStrings encapsulated by a ‘\u003cinput hwnd=’ tag will allow us to enumerate all secret entries that have been\r\ninteracted with. Below, Figure 20, is an example of extracting a private key to a bitcoin wallet.\r\nFigure 20. Extracting a bitcoin private key from a locked instance of LastPass.\r\nConclusion:\r\nAll password managers we examined sufficiently secured user secrets while in a ‘not running’ state. That is, if a\r\npassword database were to be extracted from disk and if a strong master password was used, then brute forcing of\r\na password manager would be computationally prohibitive.\r\nEach password manager also attempted to scrub secrets from memory. But residual buffers remained that\r\ncontained secrets, most likely due to memory leaks, lost memory references, or complex GUI frameworks which\r\ndo not expose internal memory management mechanisms to sanitize secrets.\r\nThis was most evident in 1Password7 where secrets, including the master password and its associated secret key,\r\nwere present in both a locked and unlocked state. This is in contrast to 1Password4, where at most, a single entry\r\nis exposed in a ‘running unlocked’ state and the master password exists in memory in an obfuscated form, but is\r\neasily recoverable. If 1Password4 scrubbed the master password memory region upon successful unlocking, it\r\nwould comply with all proposed security guarantees we outlined earlier.\r\nThis paper is not meant to criticize specific password manager implementations; however, it is to establish a\r\nreasonable minimum baseline which all password managers should comply with. It is evident that attempts are\r\nmade to scrub and sensitive memory in all password managers. However, each password manager fails in\r\nimplementing proper secrets sanitization for various reasons.\r\nThe image below, Figure 21, summarizes the results of our evaluation:\r\nhttps://www.ise.io/casestudies/password-manager-hacking/\r\nPage 15 of 18\n\nFigure 21. Summary of each password managers security items we examined.\r\nKeylogging and Clipboard sniffing are known risks and only included for user awareness, that no matter how\r\nclosely a password manager may adhere to our proposed ‘Security Guarantees’, victims of keylogging or\r\nclipboard sniffing malware/methods have no protection. However, significant violations of our proposed security\r\nguarantees are highlighted in red. In an unlocked state, all or a majority of secret records should not be extracted\r\ninto memory.  Only a single one, being actively viewed, should be extracted. Also, in an unlocked state, the master\r\npassword should not be present in either an encrypted or obfuscated form.\r\nA locked running state that exposes interacted with or all records puts users’ secret records unnecessarily at risk.\r\nMost egregious is the presence of a master password in a locked state.\r\nIt is unknown how widespread this knowledge is amongst adversaries. However, up to 60 million users of these\r\npassword managers potentially are at risk of a targeted attack directed at the software that is meant to safeguard\r\ntheir secrets.\r\nIn our opinion, the most urgent item is to sanitize secrets when a password manager is placed into a locked\r\nstate. Typically, most password managers place themselves into this locked state after a certain period of user\r\ninactivity, after this the process may remain indefinitely either until the OS is restarted, the process is terminated\r\nby the user, or the process restarts itself as part of a self-update workflow when a new version is published. This\r\ncreates a large window of time in which secrets for certain password managers reside cleartext in memory and\r\navailable for extraction.\r\nIn addition to providing a minimum set of guarantees users can rely on, creators of password managers should\r\nemploy additional defenses to protect secrets by:\r\nDetecting or employing methods to, by default, thwart software based keyloggers\r\nPreventing secrets exposure in an unlocked state\r\nEmploying hardware-based features (such as SGX) to make it more difficult to extract secrets\r\nEmploying trivial malware and runtime process modification detection mechanisms\r\nEmploying per-install binary scrambling during the install phase to make each instance a unique binary\r\nlayout to thwart trivial and advanced targeted malware\r\nLimiting the traversal of secrets to OS provided APIs by implementing custom GUI elements and memory\r\nmanagement to limit secrets exposure to well-known APIs that can be targeted by malware authors\r\nEnd users should, as always, employ security best practices to limit exposure to adversarial activity, such as:\r\nhttps://www.ise.io/casestudies/password-manager-hacking/\r\nPage 16 of 18\n\nKeeping the OS updated\r\nEnabling or utilizing well known and tested anti-virus solutions\r\nUtilizing features provided by some password managers, such as “Secure Desktop”\r\nUsing hardware wallets for immediately exploitable sensitive data such as crypto currency private keys\r\nUtilizing the auto lock feature of their OS to prevent ‘walk by’ targeted malicious activity\r\nSelecting a strong password as the master password to thwart brute force possibilities on a compromised\r\nencrypted database file\r\nUsing full disk encryption to prevent the possibility of secrets extraction in the event of crash logs and\r\nassociated memory dumps which may include decrypted password manager data\r\nShutting a password manager down completely when not in use even in a locked state (If using one that\r\ndoesn’t properly sanitize secrets upon being placed into a locked running state)\r\nFuture Research:\r\nPassword managers are an important and increasingly necessary part of our lives. In our opinion, users should\r\nexpect that their secrets are safeguarded according to a minimum set of standards that we outlined as ‘security\r\nguarantees’. Initially our assumption and expectation were that password managers are designed to safeguard\r\nsecrets in a ‘non-running state’, which we identified as true. However, we were surprised in the inconsistency in\r\nsecrets sanitization and retention in memory when in a running unlocked state and, more importantly, when placed\r\ninto a locked state.\r\nIf password managers fail to sanitize secrets in a locked running state then this will be the low hanging fruit, that\r\nprovides the path of least resistance, to successful compromise of a password manager running on a user’s\r\nworkstation.\r\nOnce the minimum set of ‘security guarantees’ is met then password managers should be re-evaluated to discover\r\nnew attack vectors that adversaries may use to compromise password managers and examine possible mitigations\r\nfor them.\r\nReferences:\r\n[1] \"1Password,\" [Online]. Available: https://1password.com.\r\n[2] \"Dashlane,\" [Online]. Available: https://www.dashlane.com/.\r\n[3] \"KeePass,\" [Online]. Available: https://keepass.info/.\r\n[4] \"LastPass,\" [Online]. Available: https://www.lastpass.com/.\r\n[5]\r\nT. Hunt. [Online]. Available: https://www.troyhunt.com/password-managers-dont-have-to-be-perfect-they-just-have-to-be-better-than-not-having-one/.\r\n[6] \"https://twitter.com/roustem,\" [Online].\r\n[7] \"https://blog.dashlane.com/10-million-users/,\" [Online].\r\nhttps://www.ise.io/casestudies/password-manager-hacking/\r\nPage 17 of 18\n\n[8] \"https://keepass.info/help/kb/trust.html,\" [Online].\r\n[9] \"https://www.lastpass.com/,\" [Online].\r\n[10]\r\nD. Florencio, C. Herley and P. C. v. Oorschot, \"An Administrator’s Guide to Internet Password\r\nResearch,\" [Online]. Available: https://www.microsoft.com/en-us/research/wp-content/uploads/2014/11/WhatsaSysadminToDo.pdf.\r\n[11]\r\nT. L. Bras, \"Online Overload – It’s Worse Than You Thought,\" [Online]. Available:\r\nhttps://blog.dashlane.com/infographic-online-overload-its-worse-than-you-thought/.\r\n[12] \"Smart Taylor,\" [Online]. Available: https://smarttaylor.io/.\r\n[13]\r\nTaylor. [Online]. Available: https://medium.com/smarttaylor/updates-on-the-taylor-hack-incident-8843238d1670.\r\n[14] [Online]. Available: http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf.\r\n[15] [Online]. Available: https://support.1password.com/pbkdf2/.\r\n[16] \"https://support.1password.com/pbkdf2/,\" [Online].\r\n[17] \"https://www.dashlane.com/download/Dashlane_SecurityWhitePaper_October2018.pdf,\" [Online].\r\n[18] \"https://keepass.info/help/base/security.html,\" [Online].\r\n[19] \"LastPass,\" [Online]. Available: https://blog.lastpass.com/2018/07/lastpass-bugcrowd-update.html/.\r\n[20]\r\nJ. Goldberg, \"Using Intel’s SGX to keep secrets even safer,\" [Online]. Available:\r\nhttps://blog.1password.com/using-intels-sgx-to-keep-secrets-even-safer/.\r\n[21]\r\n\"1Password support forum,\" [Online]. Available:\r\nhttps://discussions.agilebits.com/discussion/87834/intel-sgx-stopped-working-its-working-but-the-option-is-not-in-yet.\r\nSource: https://www.ise.io/casestudies/password-manager-hacking/\r\nhttps://www.ise.io/casestudies/password-manager-hacking/\r\nPage 18 of 18",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.ise.io/casestudies/password-manager-hacking/"
	],
	"report_names": [
		"password-manager-hacking"
	],
	"threat_actors": [
		{
			"id": "aa73cd6a-868c-4ae4-a5b2-7cb2c5ad1e9d",
			"created_at": "2022-10-25T16:07:24.139848Z",
			"updated_at": "2026-04-10T02:00:04.878798Z",
			"deleted_at": null,
			"main_name": "Safe",
			"aliases": [],
			"source_name": "ETDA:Safe",
			"tools": [
				"DebugView",
				"LZ77",
				"OpenDoc",
				"SafeDisk",
				"TypeConfig",
				"UPXShell",
				"UsbDoc",
				"UsbExe"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434356,
	"ts_updated_at": 1775791469,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/f9b4b20eca7ce5ffa6551864a2d97264af5e8eef.pdf",
		"text": "https://archive.orkl.eu/f9b4b20eca7ce5ffa6551864a2d97264af5e8eef.txt",
		"img": "https://archive.orkl.eu/f9b4b20eca7ce5ffa6551864a2d97264af5e8eef.jpg"
	}
}