Expandpass is a string expansion program. It’s “useful for cracking passwords you kinda-remember.” You tell the program what you remember about the password and it tries related passwords.
I learned about it in this article about Phil Dougherty, who helps people recover lost cryptocurrency passwords (mostly Ethereum) for a cut of the recovered value.
Powered by WPeMatico
September 18, 2019 cryptocurrency, passwords, Security technology Read more >
Many GPS trackers are shipped with the default password 123456. Many users don’t change them.
We just need to eliminate default passwords. This is an easy win.
Powered by WPeMatico
September 6, 2019 gps, passwords, Security technology, tracking Read more >
Stuart Schechter writes about the security risks of using a password manager. It’s a good piece, and nicely discusses the trade-offs around password managers: which one to choose, which passwords to store in it, and so on.
My own Password Safe is mentioned. My particular choices about security and risk is to only store passwords on my computer — not on my phone — and not to put anything in the cloud. In my way of thinking, that reduces the risks of a password manager considerably. Yes, there are losses in convenience.
Powered by WPeMatico
June 19, 2019 passwords, passwordsafe, riskassessment, risks, Security technology Read more >
I don’t have a lot of good news for you. The truth is there’s nothing we can do to protect our data from being stolen by cybercriminals and others.
Ten years ago, I could have given you all sorts of advice about using encryption, not sending information over email, securing your web connections, and a host of other things — but most of that doesn’t matter anymore. Today, your sensitive data is controlled by others, and there’s nothing you can personally to do affect its security.
I could give you advice like don’t stay at a hotel (the Marriott breach), don’t get a government clearance (the Office of Personnel Management hack), don’t store your photos online (Apple breach and others), don’t use email (many, many different breaches), and don’t have anything other than an anonymous cash-only relationship with anyone, ever (the Equifax breach). But that’s all ridiculous advice for anyone trying to live a normal life in the 21st century.
The reality is that your sensitive data has likely already been stolen, multiple times. Cybercriminals have your credit card information. They have your social security number and your mother’s maiden name. They have your address and phone number. They obtained the data by hacking any one of the hundreds of companies you entrust with the data — and you have no visibility into those companies’ security practices, and no recourse when they lose your data.
Given this, your best option is to turn your efforts toward trying to make sure that your data isn’t used against you. Enable two-factor authentication for all important accounts whenever possible. Don’t reuse passwords for anything important — and get a password manager to remember them all.
Do your best to disable the “secret questions” and other backup authentication mechanisms companies use when you forget your password — those are invariably insecure. Watch your credit reports and your bank accounts for suspicious activity. Set up credit freezes with the major credit bureaus. Be wary of email and phone calls you get from people purporting to be from companies you do business with.
Of course, it’s unlikely you will do a lot of this. Pretty much no one does. That’s because it’s annoying and inconvenient. This is the reality, though. The companies you do business with have no real incentive to secure your data. The best way for you to protect yourself is to change that incentive, which means agitating for government oversight of this space. This includes proscriptive regulations, more flexible security standards, liabilities, certification, licensing, and meaningful labeling. Once that happens, the market will step in and provide companies with the technologies they can use to secure your data.
This essay previously appeared in the Rochester Review, as part of an alumni forum that asked: “How do you best protect yourself from identity theft?”
Powered by WPeMatico
May 6, 2019 cybercrime, encryption, essays, identitytheft, passwords, Security technology Read more >
An article I co-wrote — my first law journal article — was cited by the Massachusetts Supreme Judicial Court — the state supreme court — in a case on compelled decryption.
Here’s the first, in footnote 1:
We understand the word “password” to be synonymous with other terms that cell phone users may be familiar with, such as Personal Identification Number or “passcode.” Each term refers to the personalized combination of letters or digits that, when manually entered by the user, “unlocks” a cell phone. For simplicity, we use “password” throughout. See generally, Kerr & Schneier, Encryption Workarounds, 106 Geo. L.J. 989, 990, 994, 998 (2018).
And here’s the second, in footnote 5:
We recognize that ordinary cell phone users are likely unfamiliar with the complexities of encryption technology. For instance, although entering a password “unlocks” a cell phone, the password itself is not the “encryption key” that decrypts the cell phone’s contents. See Kerr & Schneier, supra at 995. Rather, “entering the [password] decrypts the [encryption] key, enabling the key to be processed and unlocking the phone. This two-stage process is invisible to the casual user.” Id. Because the technical details of encryption technology do not play a role in our analysis, they are not worth belaboring. Accordingly, we treat the entry of a password as effectively decrypting the contents of a cell phone. For a more detailed discussion of encryption technology, see generally Kerr & Schneier, supra.
Powered by WPeMatico
March 15, 2019 academicpapers, courts, encryption, passwords, schneiernews, Security technology Read more >
There’s new research on the security of password managers, specifically 1Password, Dashlane, KeePass, and Lastpass. This work specifically looks at password leakage on the host computer. That is, does the password manager accidentally leave plaintext copies of the password lying around memory?
All password managers we examined sufficiently secured user secrets while in a “not running” state. That is, if a password database were to be extracted from disk and if a strong master password was used, then brute forcing of a password manager would be computationally prohibitive.
Each password manager also attempted to scrub secrets from memory. But residual buffers remained that contained secrets, most likely due to memory leaks, lost memory references, or complex GUI frameworks which do not expose internal memory management mechanisms to sanitize secrets.
This was most evident in 1Password7 where secrets, including the master password and its associated secret key, were present in both a locked and unlocked state. This is in contrast to 1Password4, where at most, a single entry is exposed in a “running unlocked” state and the master password exists in memory in an obfuscated form, but is easily recoverable. If 1Password4 scrubbed the master password memory region upon successful unlocking, it would comply with all proposed security guarantees we outlined earlier.
This paper is not meant to criticize specific password manager implementations; however, it is to establish a reasonable minimum baseline which all password managers should comply with. It is evident that attempts are made to scrub and sensitive memory in all password managers. However, each password manager fails in implementing proper secrets sanitization for various reasons.
For example:
LastPass obfuscates the master password while users are typing in the entry, and when the password manager enters an unlocked state, database entries are only decrypted into memory when there is user interaction. However, ISE reported that these entries persist in memory after the software enters a locked state. It was also possible for the researchers to extract the master password and interacted-with password entries due to a memory leak.
KeePass scrubs the master password from memory and is not recoverable. However, errors in workflows permitted the researchers from extracting credential entries which have been interacted with. In the case of Windows APIs, sometimes, various memory buffers which contain decrypted entries may not be scrubbed correctly.
Whether this is a big deal or not depends on whether you consider your computer to be trusted.
Several people have emailed me to ask why my own Password Safe was not included in the evaluation, and whether it has the same vulnerabilities. My guess about the former is that Password Safe isn’t as popular as the others. (This is for two reasons: 1) I don’t publicize it very much, and 2) it doesn’t have an easy way to synchronize passwords across devices or otherwise store password data in the cloud.) As to the latter: we tried to code Password Safe not to leave plaintext passwords lying around in memory.
So, Independent Security Evaluators: take a look at Password Safe.
Also, remember the vulnerabilities found in many cloud-based password managers back in 2014?
News article. Slashdot thread.
Powered by WPeMatico
February 25, 2019 encryption, passwords, passwordsafe, Security technology, securityengineering Read more >
The security is terrible:
In a very
shortlimited amount of time, three vulnerabilities have been discovered:
- Wifi credentials of the user have been recovered (stored in plaintext into the flash memory).
- No security settings. The device is completely open (no secure boot, no debug interface disabled, no flash encryption).
- Root certificate and RSA private key have been extracted.
Boing Boing post.
Powered by WPeMatico
January 30, 2019 internetofthings, passwords, Security technology, vulnerabilities, wifi Read more >
The Japanese government is going to run penetration tests against all the IoT devices in their country, in an effort to (1) figure out what’s insecure, and (2) help consumers secure them:
The survey is scheduled to kick off next month, when authorities plan to test the password security of over 200 million IoT devices, beginning with routers and web cameras. Devices in people’s homes and on enterprise networks will be tested alike.
[…]
The Japanese government’s decision to log into users’ IoT devices has sparked outrage in Japan. Many have argued that this is an unnecessary step, as the same results could be achieved by just sending a security alert to all users, as there’s no guarantee that the users found to be using default or easy-to-guess passwords would change their passwords after being notified in private.
However, the government’s plan has its technical merits. Many of today’s IoT and router botnets are being built by hackers who take over devices with default or easy-to-guess passwords.
Hackers can also build botnets with the help of exploits and vulnerabilities in router firmware, but the easiest way to assemble a botnet is by collecting the ones that users have failed to secure with custom passwords.
Securing these devices is often a pain, as some expose Telnet or SSH ports online without the users’ knowledge, and for which very few users know how to change passwords. Further, other devices also come with secret backdoor accounts that in some cases can’t be removed without a firmware update.
I am interested in the results of this survey. Japan isn’t very different from other industrialized nations in this regard, so their findings will be general. I am less optimistic about the country’s ability to secure all of this stuff — especially before the 2020 Summer Olympics.
Powered by WPeMatico
January 28, 2019 backdoors, botnets, exploits, firmware, hacking, internetofthings, japan, passwords, Security technology, vulnerabilities Read more >
I understand his frustration, but this is extreme:
When police asked Cryptopay what could have motivated Salonen to send the company a pipe bomb or, rather, two pipe bombs, which is what investigators found when they picked apart the explosive package the only thing the company could think of was that it had declined his request for a password change.
In August 2017, Salonen, a customer of Cryptopay, emailed their customer services team to ask for a new password. They refused, given that it was against the company’s privacy policy.
A fair point, as it’s never a good idea to send a new password in an email. A password-reset link is safer all round, although it’s not clear if Cryptopay offered this option to Salonen.
Powered by WPeMatico
November 16, 2018 bombs, dna, passwords, Security technology Read more >
Troy Hunt has a good essay about why passwords are here to stay, despite all their security problems:
This is why passwords aren’t going anywhere in the foreseeable future and why [insert thing here] isn’t going to kill them. No amount of focusing on how bad passwords are or how many accounts have been breached or what it costs when people can’t access their accounts is going to change that. Nor will the technical prowess of [insert thing here] change the discussion because it simply can’t compete with passwords on that one metric organisations are so focused on: usability. Sure, there’ll be edge cases and certainly there remain scenarios where higher-friction can be justified due to either the nature of the asset being protected or the demographic of the audience, but you’re not about to see your everyday e-commerce, social media or even banking sites changing en mass.
He rightly points out that biometric authentication systems — like Apple’s Face ID and fingerprint authentication — augment passwords rather than replace them. And I want to add that good two-factor systems, like Duo, also augment passwords rather than replace them.
Hacker News thread.
Powered by WPeMatico
November 5, 2018 authentication, biometrics, passwords, Security technology Read more >