I’ve always had a problem trying to get an iOS app that would work with KeePassXC databases. Seems to be working fine right from the start, so definitely worth the $6.99 price tag.
Very glad to see another post by a site, giving good information on handling passwords, security question answers, & the recommendation to use password managers. I last had a post about this in July, when Dreamhost also put out a good article about creating strong passwords for account security. The link to that article is below as well.
DreamHost recently posted an article on their site about password management: DreamHost: How to Create Strong Passwords to Keep Your Website Safe. Just the list of points is much better than what I’m used to seeing:
- Make your password long.
- Don’t use a common phrase.
- Test your password.
- Don’t reuse your password.
- Use a password manager.
- Don’t store passwords in your browser.
- Follow the rules every time.
- Use two-factor authentication.
- Consider the Passphrase/Diceware Method.
- Use security questions wisely.
- Keep an eye on your smartphone.
I still have to actually read the specifics for each, but that list alone is a great guide on modern password management.
Everyone seems to be trying to point out this “loophole” as a huge deal, getting in the way of the new feature in iOS 11.4.1 that disables the USB port for anything but charging if the device has been locked for more than an hour (or S.O.S. mode is activated on the device).
The “loophole” that people are calling a flaw is that if certain Lightning-connecting accessories are connected within the one-hour window, the timer is stopped. This does not apply to all lightning accessories, as the Lightning-to-3.5mm jack accessory does not reset the count. Apple’s Lightning-to-USB 3 Camera Adapter, however, is one of the accessories that stop the countdown. This makes perfect sense, as it allows the user to connect an accessory without the need to unlock first. If the device is in a pocket, then said accessory can just be connected. It would be one thing if Lightning accessories were trusted the same way as computers are, but that is not the case here. There is no cryptographic key exchange when connecting accessories so the device doesn’t know one accessory from another, without manufacturers making changes to their products.
This is a great step forward, making it much more difficult for attackers & warrant-skipping authorities from having virtually unlimited time to try & crack a device. Here I’m specifically thinking of the GrayKey device & any other services offered by shady companies for unlocking iOS devices.
Seeing as how the Electra 11.3.1 jailbreak is supposed to be released soon, it looks like Apple put out a statement on why you shouldn’t jailbreak: Apple: Unauthorized modification of iOS can cause security vulnerabilities, instability, shortened battery life, and other issues. I definitely find that ironic…
- Security Vulnerabilities: I’ve seen jailbreak developers release patches for devices with Cydia before Apple puts them out
- Instability: Okay, sure. But if an occasional crash is the cost of having things like themes & hooks into Springboard, it’s a price I’m willing to pay. Especially because iOS isn’t that much more stable without being jailbroken.
- Shortened Battery Life: This coming from the company that was secretly throttling older device “to save battery life”. Sorry if I don’t believe this one.
I have not yet read the rest of the page, but I’m sure it will be much of the same above. I’m not interested in Jailbreaking to download free apps; it’s for the ability to customize the device i own & want to do with as i please.
Just found this great Twitter thread: @c_pellegrino: Does T-Mobile Austria in fact store customers’ passwords in clear text @tmobileat? @PWTooStrong @Telekom_hilft
— Claudia Pellegrino (@c_pellegrino) April 4, 2018
Something good that came out of this (just for me I guess), was finding out about this web site: Plain Text Offenders.
A post by Brian Krebs on his site, https://krebsonsecurity.com prompted me to write up a post as well.
He accurately recommends not answering those Social Networking questionnaires that ask for things like “What was your first car?” or “What was your favorite teacher’s name?”, with accurate (or even ANY) details. I’m sure for many people, it’s already too late, so there is definitely another alternative: Go back to any site where you did answer these common questions, & change the answers to something else, i.e.: the answer to a different question, or just garbage text. See below for an example:
What is the name of your favorite band?
New York Yankees
Up)43!z*mP9*KXe!dChC*XLP4(mKAX)z (A random password, generated from DuckDuckGo: password 32 strong)
While the second answer may be a bit of overkill, if you are using a password manager, it’s not that hard to just make note of the Security Question answer if needed in the future.
I think I may have already posted about Password Manager options, but possibly time to take another look at what’s out there, & write up some of the ones that stand out to me. I started with Dashlane, but have since moved to KeePass (Specifically KeePassXC) due to the number of recent breaches of various companies. Using KeePass puts me in control of where I store my password databases.
Abraham Masri (iabem97) has revealed a new flaw in Apple latest iOS 11.3 beta, allowing an Info.plist file to grab a file outside of the current application’s sandbox. Granted this is a beta OS, but still, this is another example of Apple seemingly rushing a release, & having all sorts of flaws. This is just the latest one.
Redmond Pie: Abraham Masri Drops iOS 11.3 0day Vulnerability, Here’s What That Means For Future Jailbreak
And here is the Wiki write-up that explains how an app’s Info.plist file can access another app’s icon:
GitHub: iabem97/writeups: Info.plist Path Traversal
Here’s a quick excerpt from that Wiki article that shows the sandbox escape:
Yesterday it was revealed that macOS has a critical bug that allows any user with physical access to a device, to login as the root user with no password. I have tested this myself, via the process below:
- Open System Preferences > Users & Groups
- Select the lock [ ? ] in the bottom left-hand corner of the window.
- Clear the pre-filled username, & replace it with “root” & select [Unlock].
- Once the attempt is rejected, try again with the same settings as above. I’ve read from a few different sources that say to do it a few times, before you are allowed in. During my testing, I just had to attempt it twice, & I was in.
In order to fix this issue, you must change the root password through the Directory Utility. Open the app, hit the lock [ ? ] to enter your credentials (or use the root exploit again) then go to Edit > Change Root Password…
NOTE: You MUST choose to change the password. Simply disabling the root account does not correct the issue. If you disable the account, running through the same process for the exploit reactivates the root account without a password.
Bryan Krebs has made a post about this as well: Krebs on Security: MacOS High Sierra Users: Change Root Password Now.
And since creating pretty logos for exploit seems to be a thing now…: