Security software 101
Security software 101 says 'don't leave crypto materials lying around in RAM'. How can any professional developer claim to be producing secure software if they weren't even aware of this - they had to be told about it FFS!?
Password managers may leave your online crown jewels 'exposed in RAM' to malware – but hey, they're still better than the alternative
A bunch of infosec bods are taking some of the most popular password managers to task after an audit revealed some mildly annoying, non-world-ending security shortcomings. Researchers at ISE declared on Tuesday that the likes of 1Password, KeePass, LastPass, and Dashline all have vulnerabilities that would potentially allow …
-
-
Wednesday 20th February 2019 13:22 GMT Anonymous Coward
Re: Security software 101
Yes, however I always assumed that some of these password managers were (eventually) based in Gloucestershire, Maryland, Havana or Shanghai - therefore leaving artefacts around for cold-boot attack is irrelevant as they are already 'backed-up' in the cloud so-to-speak. It could even be by design, by extremely professional developers, shocked^2.
-
-
-
Wednesday 20th February 2019 14:52 GMT Anonymous Coward
Re: Security software 101
"You keep it at least hashed or XOR-ed with some other binary, then only unhash it as you are copying it out into the web page you're logging in to. It will only be a simple protection for speed, but at least it will obfuscate the RAM copy until the last moment."
And if the malware is in the browser, do these protections provide any real additional benefit?
The passwords sit in an isolated address space protected by the operating system until they need to share the passwords with other applications (i.e. browsers). If the malware has infected just the browser, the obfuscation makes little difference as it can capture a password at a time as it is passed to the browser. If the malware has admin/debug rights to other processes, accessing the memory to view both the obfuscated passwords and the obfuscation method is trivial or alternatively grab the obfuscated passwords and details of the password manager version and pass to a c'n'c server for further analysis.
Other than prompting/issuing a password challenge every time access to passwords is required, there is little that can be done other than keeping the passwords out of memory in the first place.
-
Wednesday 20th February 2019 23:22 GMT Adam 1
Re: Security software 101
> You keep it at least hashed
A hash is a cryptographic one way function. Knowing the hash, it is mathematically impossible to recovery the original string without brute forcing all possible strings and looking for one that gives the same hashed value. Being able to vomit back the original password into a password box is kinda a big thing for a password manager.
> or XOR-ed with some other binary
So where do you put that binary so the attacker can't do the same? Why don't you just put the passwords there instead.
Also, what would happen if you xor'd the obfuscated passwords together with other obfuscated passwords from that same secret binary? What can you learn about the key? What if you discover just one of those passwords in a paste bin dump then xor the obfuscated password with the known one? Oh look, secret binary in clear. Now we can read any others too.
Fun isn't it?
Even something as "simple" as clearing the secret out of memory is much harder than you might think. Depending on the runtime involved, you be relying on a garbage collector to actually overwrite the memory and you control over that process is limited. And that's before you consider whether it might be in the CPU caches which might as recent vulnerabilities show, be an oracle.
-
-
Wednesday 20th February 2019 22:30 GMT Charles 9
Re: Security software 101
Simple. You can't. As the Eyeball Mk 1 cannot grok encrypted content like in say Ghost in the Shell, information must be decrypted at some point in order to be useful. That opens you up for an "outside the envelope" attack that targets the information at a point where it must be decrypted because it is in active use.
-
-
-
-
-
Wednesday 20th February 2019 13:20 GMT JimboSmith
Re: Ha, it comes to something when the Post-it is superior to software...
I know of someone who kept password clues on a post it note under her keyboard. She was as she put it the only person who could understand what the clues referred to. She was horrified when she came home to find the yellow paper missing. It turned out her son had swapped the keyboards with his because a key he (over)used had become intermittent. Personally I have something similar but keep things in a safe.
-
Wednesday 20th February 2019 19:22 GMT unclaimedoutsider
Re: Ha, it comes to something when the Post-it is superior to software...
Post-it notes are not any more secure in this threat model. If they have gotten to a point where they can read memory they can also key log your computer. So as you type your password from the Post-it note they're recording it along with what site you used it on. Also, if you're writing down passwords you're more likely to repeat them which is a far worse then the threat model in the post. You're more likely to get your password stolen in a breach then someone getting admin rights to your computer.
-
-
-
Wednesday 20th February 2019 18:02 GMT adnim
@ Big_D Re: The alternative being memorizing a bunch of really long unique passphrases
Yes of course. I don't think clearly sometimes. And occasionally the point goes so far over my head it may as well be part of the CMB.
At least I will always have access to my passwords even if someone else does too.
Have an up vote for making me realise how I should pay more attention and think after my first coffee of the morning and not before it.
-
-
-
Wednesday 20th February 2019 08:26 GMT Anonymous Coward
This is why you need a dedicated hardware-token for things like this.
There are basically two ways to do this. You can either get a U2F token. This is pretty easy, but the website needs to specifically support it. Many don't.
The other way is to use a password manager which integrates with a token. Personally, I like pass, which uses GPG for encrypting all the passwords. If you then store your keys on the token you can only get at your passwords by having the token and entering the pincode for it. The password database is synced with git (each new or edited password automatically becomes a commit) and pushed to a repository. It also supports submodules and multi-key setup so you can have a shared submodule with passwords you need shared (e.g. with colleagues or a spouse).
-
Wednesday 20th February 2019 08:56 GMT hmv
Re: This is why you need a dedicated hardware-token for things like this.
You didn't read this article closely enough did you?
A password manager secured with a token will still be vulnerable because after you use your token to unlock the password manager (or in more extreme and probably theoretical cases when you use your token to unlock an individual entry), the target data _will_ be stored within memory in plain text.
-
Wednesday 20th February 2019 09:06 GMT Anonymous Coward
Re: This is why you need a dedicated hardware-token for things like this.
Fair enough - the entry you unlock will be available somewhere in memory. Either on the console, or in your copy-paste buffer. That's obvious because you need some way to get it into whatever form you're pasting in.
Even if your manager is completely safe, you're still pasting it into your webbrowser, which will keep it somewhere in memory until its posted.
I don't get what exactly is "extreme" or "theoretical" about a key unlocking a specific entry. This is exactly what pass does. Each password is individually encrypted and also decrypted on demand (with the use of the token).
-
Wednesday 20th February 2019 09:11 GMT big_D
Re: This is why you need a dedicated hardware-token for things like this.
Most of the solutions I've used will automatically fill in the password for you.
But the problem is, once the database is loaded, it is unencrypted in memory (1Password) or specific entries are held unecrypted in memory or cache, even after being used. This is over and above the clipboard. This is memory not being flushed properly within the programs themselves.
-
Wednesday 20th February 2019 09:19 GMT jmch
Re: This is why you need a dedicated hardware-token for things like this.
"Most of the solutions I've used will automatically fill in the password for you"
Yes, but how? To be able to do that it still needs to be passed from the password manager to the browser and so will be at some point somewhere in memory in unencrypted form. Possibly in at least 2 places, memory assigned to password manager and memory assigned to browser.
From a software point of view there needs to be a way of overwriting / deleting the password from memory a soon as it has been used, both from POV of password manager, and from POV of password field data in browser. I'm not really up-to-date with hardware / OS management of memory, but surely it should be possible to have secure memory space that isn't allowed to be accessed by anything else except the application using that space and the high-privilege routine that copies it from password manager to browser?
-
Wednesday 20th February 2019 11:12 GMT big_D
Re: This is why you need a dedicated hardware-token for things like this.
That is the point of the article, it seems like the developers have overseen how some of the system clean-up functions work and haven't enforced rigorous clean-up (E.g. overwriting the memory before releasing it).
The clipboard, browsers and other applications are beyond their control, but the safes should be ensuring that the passwords held in their memory are held safely and not leaked. Passing them on to the required application is a known risk that has to be taken into account, you can't really do anything about it with current operating system and application architectures. You'd need a new OS written from the ground up to be secure and handle information securely.
At least the developers seem to be taking it seriously, with at least LastPass have reacted and closed the hole.
-
Wednesday 20th February 2019 14:24 GMT DropBear
Re: This is why you need a dedicated hardware-token for things like this.
Trying to redouble efforts to armour plate a carrier pigeon between your password manager and browser are flat out pointless. The solution is not trying to keep a fixed string secret, but to use end-to-end crypto between a separate, physically secure piece of hardware (token) on your side and the web server on the far side; which is exactly what U2F (and partially our much downvoted OP) is trying to promote. Yes, it's not by any means universally used at this point; we can only hope it (or something like it) does become so as soon as possible.
Until then, pending cooperation from the far side, we could still have right now stand-alone hardware password vaults that type the required pass straight into a login field. Yes, they would still have remaining issues such as lack of integration for auto credential selection / inability to work with "on-screen keyboards" with variable layout / passwords lingering in the browser memory, but at least they do assure the criteria pursued by this study: that unused credentials do not get exposed, and that used ones do not linger in the _manager's_ memory once it is re-locked (or ever, considering separate hardware).
All in all, password vaults are awesome against indirect threat (where you and your hardware are not involved in an attempt to compromise an account of yours on a third-party server) but are catastrophically poor against direct threat, where your machine is compromised first either by a remote or a local attacker directly seeking to obtain credentials to exploit - so it's a compromise depending on your threat model. If, like me, your threat model includes the rest of the world... you're unavoidably fucked. Nothing can protect you comprehensively.
-
Wednesday 20th February 2019 22:36 GMT Charles 9
Re: This is why you need a dedicated hardware-token for things like this.
"...but are catastrophically poor against direct threat, where your machine is compromised first either by a remote or a local attacker directly seeking to obtain credentials to exploit..."
If you're at that point, you're in DTA territory, as the agent can play Man in the Middle against you. If they can't intercept and hijack the connection, they can at least screw it up and render it useless.
Reminds me of what I call the First Contact problem. How can Alice and Bob establish a trusted connection between themselves if they've never met before and have nothing in common, not even a Trent?
-
-
-
-
-
-
Wednesday 20th February 2019 09:05 GMT big_D
Re: This is why you need a dedicated hardware-token for things like this.
I use LastPass with a Yubikey. But that only helps when the LastPass database is closed or somebody is trying to hijack the account.
Once you have opened LastPass and used your token to log on, your database was still exposed (allegedly LastPass has now sorted out the problem).
-
Wednesday 20th February 2019 22:49 GMT Anonymous Coward
A token could work for this
If it was connected to the computer via USB or bluetooth. To wit: you 'login' to the password manager using your master password and the token. The passwords are not loaded until they are needed, and require authentication/decryption with the token (alone) on each use. That way once used they can be immediately wiped from RAM.
Of course, if an evildoer is able to read your RAM, it doesn't matter whether your password is in RAM all the time or only for 1/1000th of a second. Erasing it from RAM after use raises the bar to stealing it, but most certainly does not make it impossible.
An alternative to a token would be a face scanner. As some will rush to post every time they are mentioned, those are "usernames" not passwords. Which is perfect for this use - by determining "yes, the authorized user is present" then it can load the password into RAM. You'd need the face ID to unlock a key used to decrypt the password once it is read from stable storage, but that's easily managed by a secure enclave type solution - it isn't in RAM so the evildoer can't read it. You could do it with a fingerprint reader too, but that would require action on the part of the user, so it isn't nearly as convenient.
-
-
-
-
-
Wednesday 20th February 2019 14:06 GMT stiine
Re: Remembering loads of long passwords
Fuck hotmail.com. Many many years ago, i set up and account with a 16 character password, which worked for about 8 years. Then they changed the rules and started hashing everything you typed in, instead of just the first 15 characters. It took me a couple of hours to figure that one out that I now had to only type in 15 characters, not the 'password that I had set up'...
Fuckers.
-
-
-
Wednesday 20th February 2019 09:12 GMT Muscleguy
I use phrase initials from a number of phrases with unique identifiers for individual sites. I store these in a note app in coded form, including a Navaho wind talker style rendering of the numbers.
So even if you manage to get spyware on my Mac laptop it will have to have a very good keylogger to gain anything as even sniffing the note app data won't get you very far. I regularly run a virus sniffer (it doesn't run constantly) so I do check and I'm pretty careful about where I go on the net.
I tried 1 passport for a while but didn't get on with or really trust it. I prefer my system. I occasionally have to look up my note app and think 'what did I mean by that' but we're talking seconds.
It's better than the meaningless strings browser come up with if you let them make you a password.
Oh and the phrases, they're from my own, unpublished, poetry. So again good luck with that.
-
Wednesday 20th February 2019 10:03 GMT Anonymous Coward
including a Navaho wind talker style rendering of the numbers
Ah, like this (obligatory XKCD cartoon)?.
:)
-
Wednesday 20th February 2019 10:11 GMT Anonymous Coward
So even if you manage to get spyware on my Mac laptop it will have to have a very good keylogger to gain anything as even sniffing the note app data won't get you very far. I regularly run a virus sniffer (it doesn't run constantly) so I do check and I'm pretty careful about where I go on the net.
Ditto, although I'm having a look at re-enabling Hands Off! control (despite my dislike of anything with an exclamation mark in its name) as it also allows me to lock down disk access even more than MacOS nowadays does already.
Unfortunately, I have too many passwords floating around so I tend to use the MacOS keychain for most, but NOT backed up on iCloud because I'm no fan of 3rd party storage that is not aggressively focused on security. Where it gets sensitive, the keychain doesn't get to see them either - they're kept in a separate password manager - and even then, what is stored is not what is actually in use, and it's generally augmented with TOTP based 2 factor (not Google Authenticator, I prefer OTH Auth as it gives me more control).
Damn, my paranoia is time consuming.
:)
-
-
Wednesday 20th February 2019 10:15 GMT Anonymous Coward
Re: Keystroke logger
Single use 2FA is the only way that makes sense
Yup. Both challenge-response style OTP and single use 2FA defeat a keystroke logger, with TOTP you still have a risk of secondary login during the cycle time of the password.
I'm still looking for a good open source single use 2FA system, tips welcome.
-
-
Wednesday 20th February 2019 14:41 GMT DropBear
Re: Keystroke logger
What the hell are you talking about? Any TOTP code is by definition valid in unchanged form for 30 seconds (or other suitably chosen but nonetheless practicality-limited interval). It's up to the far side how it handles two distinct login attempts from different IPs in quick succession, but there is no "challenge" element involved in a TOTP code.
-
Wednesday 20th February 2019 15:00 GMT Anonymous Coward
Re: Keystroke logger
I've seen quite a few implementations where using the TOTP generated password on the same site with a separate browser can give you an extra login.
To prevent that from happening needs extra code that would block that particular combination of UID, PWD and 2FA token from re-use for one TOTP cycle past login. It can be done, but in my experience it usually is not.
-
-
Wednesday 20th February 2019 15:49 GMT Anonymous Coward
Re: Keystroke logger
There's no shortage of one-time pads with open-source implementations.
The U2F/Webauthn systems have published specifications, open source implementations on the server side, and there's a few open hardware+software FIDO2 keys. You can set up your server to insist upon the key having a "user presence" attestation, such as a press button.
If it's a open source password manager with second-factor you are looking for then keepassxc works with Challenge-Response keys, such as Yubikey. The Response is used to contribute to the key material to decrypt the database. No Response, no decryption, so if a keylogger grabs the password it's still not enough.
-
-
Wednesday 20th February 2019 09:42 GMT Starace
Shocking
You mean something that has to pass a password to a text entry field on something else might actually expose your password at some point? Who'd a thunk it?
Even if the thing is engineered 'properly' there are still going to be gaps if you're infested with malware.
Hint: a secure system isn't one with malware on it.
-
Wednesday 20th February 2019 10:19 GMT Anonymous Coward
Re: Shocking
With malware you could indeed end up with a pop-under remote control session if the application doesn't prevent a user from spawning multiple windows when clogged in (i.e. allow sharing of session credentials between windows), but challenge-response style authentication as used with the "calculator" style devices you need to stick your bank card in tends to clean up the problems with password leakage as the password is (a) different every time and (b) generated externally.
-
-
Wednesday 20th February 2019 09:51 GMT A Non e-mouse
Baby & Bathwater
Several commentards are coming up with ways on how to make password managers better (or something better than a password manager) Let's not forget the basic piece of advice: Using a password manager (With their design flaws) and having unique, strong passwords for every website is still a heck of a lot better than using the same poorly chosen passwords a
-
Wednesday 20th February 2019 09:57 GMT Anonymous Coward
They missed one: SecureSafe
.. but that may be because it does more than just manage passwords.
I have been using Swiss based SecureSafe for years. I know the IT people in the Swiss bank that reviewed (to recommend it to their clients) it so I know it's solid and it's a proper Swiss company, not one of these US outfits that got themselves a Swiss office to appear Swiss and so hide that they are subject to the US Cloud Act 2018 (there's more, but that's another story altogether).
I also like it because of its inheritance feature, something that would have prevented, for instance, the problems at Quadriga. The idea is that you flag the passwords that can be "inherited" and then generate a sort of "override" password that you can give , but that override takes a few days to activate. During that countdown, it emails the account holder every day that the clock is ticking down. That means that if someone tries to abuse the feature, the account holder simply generates a new inheritance password (and then, one assumes, finds someone else to trust with the inheritance password), no harm done.
I have personally no use for the document feature which is where they seem to draw their income from, but I'm guessing it's good for people who have lots to share, or maybe have lots of bank accounts :).
-
-
Thursday 21st February 2019 14:31 GMT Anonymous Coward
Re: They missed one: SecureSafe
AFAIK they didn't disappear, they became inaccessible. There's a difference.
That said, I don't know enough of the ecosystem to ask sensible questions, but the phrase "artificial scarcity" sprang to mind when I heard of a large batch of coins apparently becoming inaccessible, but that might just be my devious mind..
-
Thursday 21st February 2019 19:01 GMT Anonymous Coward
Re: They missed one: SecureSafe
My devious mind concluded the majority of the bitcoins never existed in the first place.
Having one person holding all the keys for $250m seems a little risky. Having said person die, preventing anyone getting any of the money back almost seems....convenient?
-
-
-
-
Wednesday 20th February 2019 10:02 GMT ElReg!comments!Pierre
Remembering long passphrases
"Sec 101 : This is my passphrase for El Reg" is
- unique
- easy to remember
- virtually uncrackable by automated means
- tedious to type
- not even close to my actual credentials
- as weak as "password123" as soon as your system is compromised, because keylogger.
The "remembering" part is secondary in this problem. Login security will always be hampered by
- Joe Public's unwillingness to type a 20+ characters password to let the world know of their opinion on May's or Trump's latest tweet (see the success of the oh-so-very-innocuous "login with Facebook" option on various websites)
- the hard fact that once your system is compromised, any input, output or locally stored data (including in RAM) can be snooped on (although the efforts needed to do so may vary depending on your security measures).
-
Wednesday 20th February 2019 11:26 GMT Version 1.0
Heads up folks
We are started seeing a lot of incoming infection attempts related to Brexit:
X-Scan-Result: infected
X-Scan-VirusName: PDF/Trojan.PHVR-3
X-BadQueue-Reason: WARNING! infected with virus (PDF/Trojan.PHVR-3)
Reply-to: eBusiness Number <contact@ebusinessnumber.eu>
Subject: eBusiness Number registry for 2019/2020
-
Wednesday 20th February 2019 11:32 GMT NonSSL-Login
Could do better but not much better
It looks like all the major players in the Password Manager area have done a fair amount of work to try and protect content in memory and scrub after use but need to make small changes to slightly improve it this. At the same time, with your machine already being accessible some of the changes will make no difference anyway.
Better to fix them than not fixing them but in the big picture, it's nothing we didn't know already. Code has been created before to extract and dump the content of unencrypted password managers to screen or file and it will always be possible one way or the other. Even if only one entry is decrypted as it's used, that means the master password or secret is somewhere in memory in some form, just waiting for someone to work out a way to reverse it. Or whatever is watching on that machine waits for every password to be used.
Keepass came out well in their summary table, so I get to feel smug running that on Linux :)
-
-
Thursday 21st February 2019 16:52 GMT FrogsAndChips
Re: Could do better but not much better
If you're referring to Fig 21 in the paper, KeePass comes out with 2 Green and 2 Amber, that's the best score of the 5 surveyed tools.
Assuming 2 points for Green, 1 for Amber, 0 for Red, you get the ranking: KeePass > 1Password4 > Dashlane > LastPass > 1Password7.
YMMV if you weigh the weaknesses differently.
-
-
-
This post has been deleted by its author
-
Wednesday 20th February 2019 11:57 GMT Lee D
If you are asking software to show you / allow you to copy / etc. your password, then that password is fundamentally electronically available to anything else running as the same user.
If you want to run password software, run it as an entirely different user, or on a entirely different device, to that which you utilise the services.
An "offline" phone holding this stuff in a memo, or even a notepad, is thus fundamentally more secure in such instances. They have other flaws (the former, I'm hard pushed to think of one... you can encrypt it, you can fingerprint-lock it, you can back it up, you can afford to both secure and lose the device, etc.) but they are no less secure.
The problem is that we are STILL running computers as "just one user", in effect. All your processes can sniff other processes RAM, anything that runs as the same user, in fact. All your word processors, web browsers and password managers are running as that same user with no proper isolation. You're more isolated from the DNS client service in Windows than you are your own password manager - at least that runs as an entirely different user.
Sorry, but all the password manager nonsense is just that. If you want to secure your passwords, run such a "password manager" entirely offline, on a separate device, that's not useful if stolen and can't be easily "hacked" (i.e. encryption and keep it in Aeroplane mode without a SIM). A tablet would do, and may help with the "I don't know what the GSM chip is doing".
But if you want the convenience of something that will copy/paste your passwords into third-party applications for you, then it's going to expose them to RAM, and they'll be sniffable as anything that you've allowed to run. As such, it's no more secure than, say, Chrome's in-built save-password functionality.
Sure, it's inconvenient to have to have another device to do all that. Convenience trades off against security, though.
Hell, if you really want to, get something with GPS (so that you can keep the clock updated without being "online") and also use it for, e.g. 2FA TOTP apps for any services that support that (so you can *safely* type those passwords into a pseudo-compromised machine and it won't matter as they won't be valid by the time anyone else tries to use them).
But a password manager running as your browser-user is pointless. A password manager with the convenience of plain-text copy/paste (or even display) on the same device as you're entering the password is useless. A password manager itself - especially if it requires Internet connectivity of any kind - is just another layer of risk around your passwords.
Old phone/tablet. Encrypt it. Install a couple of apps. Kill its offline connections. THEN store your passwords on it. Maybe use GPS timesync and whatever OTP apps you need if you want it to generate OTP tokens (they should only need a fairly-accurate time, not Internet).
Leave it in your house and are burgled? No problem.
Someone gets in your PC? Problem, but they won't have any password you haven't saved on that PC somehow.
Difficulty of using? "Oh, what's that password?". Turn on. Check list. Turn off.
Difficulty of replicating? Ten minutes, the encryption password / fingerprint, and another similar device.
I bought an Android tablet off Amazon for £10, it has no GSM and doesn't connect to any Wifi, let's me encrypt the SD card, and has passcode/passphrase login. That's more secure than any of this password manager tosh.
-
-
Wednesday 20th February 2019 16:36 GMT Lee D
Easy... I don't use ridiculous passwords like that, that add almost nothing to security.
N letters combined from an alphabet of M letters = M^N possible combinations. N grows the possibilities WAY FASTER than M ever could.
An 8-character all ASCII-typeable characters (128^8) password is beaten by a 10-character plain A-Z,a-z password (52^10) by an order of magnitude.
And that's *purely* a brute-force defence, which shouldn't be viable against any active online service (offline attacks on an encrypted volume, etc., may be different - if someone steals it they can easily bypass any limits on how many they can try a second. Anything else - e.g. your servers, Google, online services, etc., they can't. Hell, even the FBI struggled against an iPad's lock-screen reset)
Stop believing nonsense password advice, and go check what people like NCSC etc. actually say.
P.S. No regular password resets either. Seriously, just stop it. Even the guy who first advised that (for an American cyber-security agency's publications) says it's stupid, one of his biggest ever mistakes, and to stop doing that.
-
Thursday 21st February 2019 09:22 GMT Anonymous Coward
"An 8-character all ASCII-typeable characters (128^8) password is beaten by a 10-character plain A-Z,a-z password (52^10) by an order of magnitude."
Your mathes is right, but the result is so wrong. Current hashing tools on a single high end PC (i.e hascat on a nVidia 1070) will be doing around 1 billion hashes a second - cracking rigs with 100x this power are available (high end desktop with 8x1080Ti) and multiple machines can share the workload further either in one location or by distributing the workload across multiple machines in multiple locations, putting the output at around 1x10^12 hashes/second. You should be aiming for 14 characters+
Simple things like Windows being involved in password storage and using cached credentials will allow password recovery by forcing legacy options that further reduce strength of short passwords.
Use any patterns for your passwords that are "unique to you"? Once you get access to a large password dump and run cracking/hashing tools against them, you realise just how common many peoples methods of creating "hard" passwords are. Write rules to meet those patterns, pump the result through hashcat and you're down to just the systems password implementation (i.e. correct use of salt, number of rounds of hashing, no known implementation flaws) to protect you.
-
Wednesday 20th February 2019 13:11 GMT Giovani Tapini
The most relevant comment in the article
is the one that says security of your passwords is not an issue until you open the password manager that uses them...
Ultimately you can throws layers of defence around access to your machine, it's services, the OS, etc. etc, but as soon as data has to be used or seen it is at risk. This suggests that the only safe data is that which is never accessed and not accessible. Otherwise there will always be threat vectors.
I would like to think that these tools will be fixed where the entire password catalogue is stored in plaintext, and they are decrypted on demand. But decrypted they must be while systems are accessed in a way where credentials must be entered. The benefit of this, is that I own my own credentials (albeit with described risks) whereas a lot of the alternatives you have to trust someone else and their own infrastructure to manage your identity for you.
Big Brother, or incompetence could make this more catastrophic than the loss of individuals credentials if they happen to be the one unlucky enough to be compromised. Bearing in mind the general public don't even seem to care about being compromised unless it slows down facebook too much we, although right, are not barking up the right tree.
-
Wednesday 20th February 2019 15:26 GMT DCFusor
Genuinely hard to get right
Several people seem not to understand that some ram (and disk!) is not controlled or controllable by your password app. And certainly not cache.
The GUI tools that all apps use these days keep the text in ram - even a terminal emulator does, and some even save that in history. The browser keeps the text in ram at least long enough to send your password *in plaintext* down the wire, and maybe doesn't get it erased due to sloppy coding - or using the GUI tools from the opsys, as we all more or less do (and on all opsys). Gonna write your own windowing and textbox code, really? And then hope that the opsys doesn't somehow keep a bit of that around in a screen buffer (in the extreme case).
Most people these days have *no clue whatever* how the magic really works inside. Swap files? I could go on for longer than this edit box will take, and no one read it. Hope you get the point.
Even if this was all public/private signed stuff where the password was sent encoded with a key only you and the site know (already) - there would be replay attacks possible - even in these days dumber-easier stuff like sql injection still works on many sites. This would be subject to a similar batch of code-at-screen noobs errors who are usually the ones hired cheap to develop web pages.
This is a genuinely hard problem...
And as pointed out in the article, if you're already owned locally, this is just a quicker pivot technique to own you on all the sites you visit *too*.
-
Thursday 21st February 2019 04:04 GMT canthinkofagoodname
Cool find and all, but for the all the bad scenarios...
Should be fairly straight forward:
- Identify risks / threats
- Assess risks / threats (inc. existing mitigations, and predisposing conditions for risk realisation)
- Accept and/or mitigate risks / threats
- Manage risks / threats
It's what we do for just about any other vulnerability or flaw in a system, why should this finding be any different?
-
Friday 22nd February 2019 02:06 GMT Gustavo Fring
on death
So your stuff , inckuding financials , is secure, you've opted for paperless billing, so when you die (inevitable!) who knows what you've got and how to get at it . I like the 2fa using SMS , seems ok to me ... except steam , seems to not work.
HSBC now can use voice authentication to access bank account .. will take that up soon....
Which password manger tho ? dashlane 1password.. what ?
Biting the hand that feeds IT
