|
ChickenWing posted:Sorry, should have qualified - what does using a non-corporate VPN do? Like, is there any real reason for me, an average joe who is not a whistleblower or confidential source or policitcally important person, to subscribe to Joe's Logless VPN Hut? Where VPN technology will actually have a use case for a home user is to securely access resources on your home network remotely. Making your NAS or desktop visible on the internet isn't a very good idea, so instead you have a VPN server running on your router or some other device which is the only thing facing the public internet. In simple terms your phone or laptop connects to your VPN server and now your device acts like it's connected to your home wifi, so I can stream music, play videos or RDP into my computer while I'm staying with family. When you purchase a subscription to a commercial "VPN service" all you're doing is routing your home connection through their server, which is of questionable benefit at best.
|
#
?
Feb 25, 2021 13:08
|
|
|
|
| # ? May 24, 2024 22:27 |
|
|
Gotcha, that's about what I figured. If I ever find myself in need of internal network access I'll care about setting one up ~properly~ but otherwise continue not caring about XX% off nordvpn or whatever ads
|
|
#
?
Feb 25, 2021 20:08
|
|
|
A coworker is running a VPN server on UDP port 53 (DNS), this may enable free access for example from airport wifi.
|
|
#
?
Mar 1, 2021 15:49
|
|
|
Rooted Vegetable posted:Adjacent question here, how should one manage recovery codes? I've got about 15 accounts recovery codes and the best solution I have found that's truely cross platform and offline is ultimately storing them as a simple text file on a usb flash drive (2 of them actually). I thought I'd come back with an answer for my own question in a timely within 2 years blink of an eye. I've still only partly answered it (still have to figure out how to reliably stop both USB drives getting corrupted somehow) but it's a start. Long story short: I plan to change my backup text file of 2FA/MFA Keys and Recovery Codes to a KeypassXC database No one was really talking too much on the topic of protecting your recovery codes in significant detail, but one article about backing up your entire password manager lead me to the idea. Essentially I will create a KeypassXC database that I'll treat like my text file e.g. open on airgapped machines if possible, keep on a physically disconnected USB stick and copy it to another stick for backup's sake, lock them somewhere safe. I'll use a decent password in case of casual loss. Assuming that whomever steals it happens to be a cryptography expert who's taken up physical burglary to pay his supercomputer bills, that should give me at least time to change the MFA keys before they can be used. In addition, I'll stick the AppImage version of the Linux app, the portable Windows app and the Mac app on there for ease of later use. This gets round a few things: KeypassXC's UI is designed for managing secrets that are ultimately plain text and change somewhat rarely (although things are added), and it has a nifty SSH agent too. Before I go ahead with this, any thoughts?
|
|
#
?
Mar 4, 2021 10:20
|
|
|
I use keepass for storing it, you can back it up however you want but the easiest way is dropbox/other cloud host. You want low-friction for accessing these if you ever need to. For instance if you lose your phone on vacation and need to be able to access banking / other accounts. It should not matter where you leave your encrypted data blob. If there's a theoretical assailant able to compromise 256bit AES, they could destroy the entire world's economy, so your password vault is pretty small-fry to say the least.
|
|
#
?
Mar 4, 2021 13:21
|
|
|
Khablam posted:If there's a theoretical assailant able to compromise 256bit AES, they could destroy the entire world's economy, so your password vault is pretty small-fry to say the least. You know this quote really helps a lot in deciding to do this. I'm converting it now. I'm perhaps more worried about my own stupidity (e.g. somehow leaving it open and having the bad luck of someone wanting to export everything as plain text) so I'll keep the physical barrier for now, but you make a compelling case to make this not quite so inaccessible.
|
|
#
?
Mar 4, 2021 18:11
|
|
|
Rooted Vegetable posted:You know this quote really helps a lot in deciding to do this. I'm converting it now. Fun thing about keepass: it autolocks so you can't just leave it open all the time. Having lost access to my vault at inopportune times before, take their advice and trust the security of the vault.
|
|
#
?
Mar 4, 2021 18:51
|
|
|
True but not loosing sight of where I started here. In order to loose access I'd have to loose my phone and any backup devices (installed on my daughter's tablet with a strong pin). Assuming I'm away from home I'd then have to walk someone through getting into my place and sending me the contents of a USB drive. It's rare enough that I think I'll take the risk. I do take your point about trusting the vault though. However, all of my cloud services are protected by the very MFA means I'm trying to back up, so I could unintentionally lock myself away from it.
|
|
#
?
Mar 4, 2021 20:45
|
|
|
My current setup is that I have a main Keepass database, which is on Dropbox, protected by a frankly suboptimal but easy to type passphrase and also by a key file. The keyfile is definitely not on Dropbox, nor is it in cloud backups. If my house ever burns down and I leave without my phone, I'm pretty well screwed. The passphrase for my Authy account, which has all my 2FA seeds in it, is in a separate Keepass database which is also not in cloud storage nor cloud backups. It exists only on my desktop PC, my phone, and my iPad. Unless I'm missing something, I'm safe unless someone gets hold of one of those devices long enough to brute force my password before I notice that there's a problem and start changing passwords. Granted, the resulting password changes would suuuuuuck.
|
|
#
?
Mar 5, 2021 00:46
|
|
|
Zorak of Michigan posted:My current setup is that I have a main Keepass database, which is on Dropbox, protected by a frankly suboptimal but easy to type passphrase and also by a key file. The keyfile is definitely not on Dropbox, nor is it in cloud backups. If my house ever burns down and I leave without my phone, I'm pretty well screwed. The passphrase for my Authy account, which has all my 2FA seeds in it, is in a separate Keepass database which is also not in cloud storage nor cloud backups. It exists only on my desktop PC, my phone, and my iPad. Unless I'm missing something, I'm safe unless someone gets hold of one of those devices long enough to brute force my password before I notice that there's a problem and start changing passwords. Granted, the resulting password changes would suuuuuuck. Keyfile in a safe deposit box if you have one, or encrypted and given to your attorney or a friend or family member whom you would trust not to lose or try to crack it is an enhancement to this scheme, though depending on your circumstances you may not have any of those or wish to expend the resources to get them.
|
|
#
?
Mar 5, 2021 04:26
|
|
|
If you want to roleplay hackerman, by all means do that. The easiest way to have a keyfile is to just make it an existing file you have easy access to but which the identity/use of is a secret. It could for example be Google's valentines day logo in 2015, a copy of which you can get from the waybackmachine at any time, one of 20k photos sitting in your google photos backup, the sourcecode from LAME3.90 ... it doesn't matter what it is as long as you can always access an identical version of the same file.
|
|
#
?
Mar 5, 2021 05:17
|
|
|
Midjack posted:Keyfile in a safe deposit box if you have one, or encrypted and given to your attorney or a friend or family member whom you would trust not to lose or try to crack it is an enhancement to this scheme, though depending on your circumstances you may not have any of those or wish to expend the resources to get them. I think it's worth repeating that whenever you go down the road of securing your things you should have a good think about what your threat model actually is. This includes evaluating yourself as a target. I'd be willing to bet that the large majority of people here on SA, myself included, are effectively nobodies with little in the way of valuable assets. If you fall into that category, and you probably do, then you're a low-value target and only need to worry about the same poo poo as everyone else: scams, malware and phishing. If you're in this category then leaving poo poo like encryption keys or MFA recovery codes in a safe deposit box or with an attorney offers no more protection than leaving them on a piece of paper or a HDD at home. Further to considering yourself as a target you need to consider what possible threats you might face because there are many that you as an individual can't do poo poo to mitigate. An oft used example is if Mossad wanted your AES 512-bit encrypted data. In that case they'd simply kidnap and torture you to get the key! That of course isn't a threat any of us would face but it goes to show how many security measures kind of fall apart if you're just an individual without corporate/government backing. To summarise, just go with what is sensible and easy. Unless you're Alexei Navalny enabling MFA on everything, using unique passwords for every single service, using a password manager, running ad-block, installing software/OS updates on your phone+PC and not clicking links in e-mails will protect you from 99% of potential threats. Anything more is probably unnecessary.
|
|
#
?
Mar 5, 2021 13:46
|
|
|
Pile Of Garbage posted:If you're in this category then leaving poo poo like encryption keys or MFA recovery codes in a safe deposit box or with an attorney offers no more protection than leaving them on a piece of paper or a HDD at home. Zorak of Michigan posted:If my house ever burns down and I leave without my phone, I'm pretty well screwed. Key file held off premises addresses house burning down with phone in it.
|
|
#
?
Mar 5, 2021 15:58
|
|
|
That's a good point, I am a massive dingus!
|
|
#
?
Mar 5, 2021 16:05
|
|
|
It also prevents you being able to get your keyfile until you can get to your security lockbox, which you may be physically distant from, may even have trouble accessing if your ID was in the charred remains of your house. The best way to have a keyfile is obfuscation. Don't have "my keyfile.keyx" and decide you have to hide it, just use some commonly available file, but I repeat myself.
|
|
#
?
Mar 5, 2021 18:02
|
|
|
Wait a minute this is all dumb. If the risk is "a fire obliterates your house and all your belongings" then your lock-box key is probably toast as well. Just get a fire-proof safe or put your key on some cloud service that's separated from your other stuff.Khablam posted:The best way to have a keyfile is obfuscation. Don't have "my keyfile.keyx" and decide you have to hide it, just use some commonly available file, but I repeat myself. So you're advocating for security through obscurity? You do know forensic file system tools exist right? They can look through a whole bunch of files and immediately ID anything that's out of place (NTFS Alternate Data Streams, weird EXIF data, file data structure not matching header, other sneaky poo poo I don't know about plus most of the common steganography techniques). If you really wanted to hide the file in such a fashion you'd have to be real fuckin sneaky about it, so much so that you'd end up having to record where and how you've hidden it because there's no guarantee that you'll remember whatever arcane process you used.
|
|
#
?
Mar 5, 2021 18:51
|
|
|
He’s not talking about modifying the file in any way. Just using the file bytes as the key I have two very strong passwords that I need to remember. My onedrive password, and the password to my keepass vault file. I am protected
|
|
#
?
Mar 5, 2021 18:57
|
|
|
Pile Of Garbage posted:Wait a minute this is all dumb. If the risk is "a fire obliterates your house and all your belongings" then your lock-box key is probably toast as well. Huh??? Under what circumstances? Either you're home at the time and A) die in the fire, or B) evacuate with basic belongings like your keys and wallet and stuff, or you're not at home and you have your keys and wallet and stuff with you. In both cases you're either dead or have your keys, and why wouldn't your lockbox key be among them?
|
|
#
?
Mar 5, 2021 19:02
|
|
|
Pile Of Garbage posted:So you're advocating for security through obscurity? You do know forensic file system tools exist right? They can look through a whole bunch of files and immediately ID anything that's out of place (NTFS Alternate Data Streams, weird EXIF data, file data structure not matching header, other sneaky poo poo I don't know about plus most of the common steganography techniques). Which means it doesn't matter what your keyfile is, only that you know what it is. Given this there's no reason to try to physically lock it away - as long as you know which of 20k photos you can restore from anywhere and use, you can... well use it. Same goes for any consistently hashable file you can get and use from anywhere. I say this because for 99.99% of people, they're going to reduce their ability to use their own password vault far before they reduce their security.
|
|
#
?
Mar 5, 2021 19:08
|
|
|
On Windows machines, a better approach is to lock down the key file, not obfuscate it. On my machines, I set access to that keyfile to admins only, and set KeePass.exe to run elevated (UAC prompt). It's nice that it's a code-signed exe, because you get the blue UAC prompt with the author's name. This accomplishes a number of things: malware.exe that I accidentally kicked off in user space can't read the key file, and process isolation in Windows means the memory used by KeePass (elevated process) is also protected from user-level process snooping.
|
|
#
?
Mar 5, 2021 19:21
|
|
|
Cup Runneth Over posted:Huh??? Under what circumstances? Either you're home at the time and A) die in the fire, or B) evacuate with basic belongings like your keys and wallet and stuff, or you're not at home and you have your keys and wallet and stuff with you. In both cases you're either dead or have your keys, and why wouldn't your lockbox key be among them? Complete destruction of all the poo poo was the premise Midjack posted up-thread: Midjack posted:
I agree it's probably unlikely but disaster planning is about assessing likelihood, impact and mitigation together. Khablam posted:A keyfile is just a second-factor that stops someone accessing your vault if they can a) get a copy and b)get your password. Nothing about using a holiday snap of a pier makes it any less secure. If they can ID and lift your keyfile, it also doesn't matter what it is. Correct me if I'm wrong but are you suggesting that the keyfile be stored adjacent to the vault? If that's the case then you're effectively nullifying any benefits that a keyfile would provide. The whole point of a second-factor is that an attacker doesn't have it. B-Nasty posted:On Windows machines, a better approach is to lock down the key file, not obfuscate it. A few issues here:
IMO a better approach is to store your key file on a separate volume encrypted with BitLocker (Passphrase AKA BitLocker To Go, not TPM) and to enable Ransomware Protection to control access to the volume/folder containing the key file (Assuming you're running Win10 which you should be). Furthermore you should ensure that KeePass is configured correctly, specifically the automatic lock and clipboard clearing options. Edit: should probably add that the Ransomware Protection/Controlled Folder Access feature in Win10 isn't infallible so as always make sure to keep your system up-to-date. Edit 2: if you're using Ransomware Protection/Controlled Folder Access and enable access to a location for say cmd.exe or powershell.exe you are basically screwing yourself. It's easy to shoot yourself in the foot so you gotta be careful. Pile Of Garbage fucked around with this message at 20:27 on Mar 5, 2021 |
|
#
?
Mar 5, 2021 20:23
|
|
|
Pile Of Garbage posted:Restricting NTFS permissions doesn't mean much if someone can elevate to SYSTEM context. That's true, but kind of ridiculous. If malware can use an exploit to elevate or inject into a trusted process (these are rare), or you elevate it by UAC-clickthrough, you're hosed. Controlled folder access won't protect you at that point either. Pile Of Garbage posted:Regarding the likelihood of your KeePass EXE being compromised, supply-chain attacks against popular software packages are far from uncommon so inadvertently installing a malicious update is a real possibility. A risk, for sure, but consider that you're also trusting all your passwords to that application. At least with a local app like KeePass, you can choose to not install updates. With auto-updated browser extensions or online password services, you could be hit with this attack at any time. I do agree that it would probably be more secure to store your keyfile on removable (or encrypted-by-default) media that you only mount when you want to open your PW DB, but that adds too much inconvenience for my liking.
|
|
#
?
Mar 5, 2021 21:46
|
|
|
B-Nasty posted:That's true, but kind of ridiculous. If malware can use an exploit to elevate or inject into a trusted process (these are rare), or you elevate it by UAC-clickthrough, you're hosed. Controlled folder access won't protect you at that point either. Just tested it and it does block access by elevated processes to protected locations. Of course if you can elevate privilege you can modify the allow list. Also it only blocks writes and not reads so kinda pointless in retrospect (I'm constantly wrong lmao). B-Nasty posted:A risk, for sure, but consider that you're also trusting all your passwords to that application. At least with a local app like KeePass, you can choose to not install updates. With auto-updated browser extensions or online password services, you could be hit with this attack at any time. Just to note I never advocated using any browser extensions or cloud password managers, rather just using a cloud storage service to store the key file, ideally one that isn't linked to any of your other accounts, the idea being to not store the keyfile adjacent to the vault itself because if you do that then the keyfile is no better than a password.
|
|
#
?
Mar 5, 2021 22:06
|
|
|
Pile Of Garbage posted:Just to note I never advocated using any browser extensions or cloud password managers, rather just using a cloud storage service to store the key file, ideally one that isn't linked to any of your other accounts, the idea being to not store the keyfile adjacent to the vault itself because if you do that then the keyfile is no better than a password. Totally agree with that. I think the local (never cloud) keyfile combined with a password offers a significant added layer of protection for the most likely attack vectors. It's one of the strongest reasons why something like KeePass that supports it is so much more secure than a password-only vault. A simple keylogger snagging your password won't do it, and I feel absolutely comfortable uploading the database to the cloud, even if I have a crappy password, because the keyfile adds an additional 256bits of totally random entropy to my brute-forceable 'fuzzybunnies69'
|
|
#
?
Mar 5, 2021 22:23
|
|
|
Time to build a new healthy password habit methinks... that is to start to use passphrases as opposed to passwords. The EFF like them too. That page, KeepassXC and Bitwarden all have good passphrase generators. If you want an entirely offline method, the EFF have help for that too. Some of my more sensitive accounts (Google, Protonmail, Bitwarden) for instance are getting a little upgrade once I can memorise a few.
|
|
#
?
Mar 5, 2021 22:38
|
|
|
Pile Of Garbage posted:Correct me if I'm wrong but are you suggesting that the keyfile be stored adjacent to the vault? If that's the case then you're effectively nullifying any benefits that a keyfile would provide. The whole point of a second-factor is that an attacker doesn't have it. If an attacker knows they have your password DB and your password, they're going to try to use it. If it doesn't work they're not going to then upload the entire contents of your HDD to hand-test every file on your disk. There's a tiny chance some malware searches and copies a *.keyx file, which makes the whole part about creating a keyfile and storing it alongside gold bullion under a mountain somewhere nothing more than self-imposed security theatre. If someone does have enough access to observe the file being used for this, which file you used in particular has ceased to matter. Like there's just no scenario where it being on a bitlocker drive in a safe on a nuclear submarine is actually a benefit to you.
|
|
#
?
Mar 5, 2021 22:41
|
|
|
Rooted Vegetable posted:Some of my more sensitive accounts (Google, Protonmail, Bitwarden) for instance are getting a little upgrade once I can memorise a few. If you're taking the time to rotate passwords on your accounts check that you've also got 2FA enabled for them, ideally using TOTP instead of SMS. As I've found in the past some services often just add 2FA support with little fanfare or announcement. All of that is entirely unnecessary if you just store your keyfile separately from the drat vault.
|
|
#
?
Mar 5, 2021 22:49
|
|
|
Pile Of Garbage posted:All of that is entirely unnecessary if you just store your keyfile separately from the drat vault. All you're doing is adding a biometric lock to a room with a skylight and caring about how secure the scanner is. Someone is either going to climb on the roof or not bother, and find someone else with a skylight.
|
|
#
?
Mar 5, 2021 23:06
|
|
|
Pile Of Garbage posted:If you're taking the time to rotate passwords on your accounts check that you've also got 2FA enabled for them, ideally using TOTP instead of SMS. As I've found in the past some services often just add 2FA support with little fanfare or announcement. I absolutely agree. I went for the major accounts some time ago but always keep an eye out. I would be linking to two factor auth dot org at this point but it appears that whomever owned that awesome list sold/lost control of the domain and now it redirects to a vendor page.
|
|
#
?
Mar 5, 2021 23:58
|
|
|
Khablam posted:If something is lifting your key file it's doing it when you use it. Whether you got it out of a safe or not, you're still doing a file open on the file when you unlock it. There's no other practical way to both identify and copy the key file. A lot of people here don't seem to understand security is only secure if it actually protects you. This analogy is spot on.
|
|
#
?
Mar 6, 2021 20:10
|
|
|
alexandriao posted:A lot of people here don't seem to understand security is only secure if it actually protects you. This analogy is spot on. Like owning a PPK in the bedside table for self defense. Some folks want you to keep it in a gun safe with a trigger lock/magazine lock with ammo stored somewhere else. Kinda defeats the whole point. (USER WAS PUT ON PROBATION FOR THIS POST)
|
|
#
?
Mar 7, 2021 03:00
|
|
|
Khablam posted:If something is lifting your key file it's doing it when you use it. Whether you got it out of a safe or not, you're still doing a file open on the file when you unlock it. There's no other practical way to both identify and copy the key file. Wait I think there's been some confusion. I assumed that we were talking about a KeePass DB that is secured with a key file and that you were suggesting that it is OK to keep the KeePass DB and the key file on the same volume as long as you "hide" the key file amongst a bunch of other files. My argument is that it's a bad idea to keep the KeePass DB and key file on the same volume. Because people love analogies apparently: storing the KeePass DB and the key file on the same volume is like locking your front door and then leaving the key in the lock. In fact the KeePass documentation actually points out that "hiding" the key file doesn't increase security at all (Source): quote:Hiding the location. The key file content must be kept secret, not its location (file path/name). Trying to hide the key file (e.g. by storing it among a thousand other files, in the hope that an attacker does not know which file is the correct one) typically does not increase the security, because it is easy to find out the correct file (e.g. by inspecting the last access times of files, lists of recently used files of the operating system, file system auditing logs, anti-virus software logs, etc.). KeePass has an option for remembering the paths of key files, which is turned on by default; turning it off typically just decreases the usability without increasing the security. The documentation also points out the importance of keeping the key file and DB in separate locations (Admittedly I never read it until today). Of course if I have misunderstood you and you are talking about something else then carry on. Edit: note that maintaining separation between the KeePass DB and the key file only protects you in the event that someone obtains a copy of the DB as without the key file it is useless. Obviously if you're using the DB on a compromised system you're screwed anyway but that should never dissuade you or anyone practising good security. Pile Of Garbage fucked around with this message at 11:43 on Mar 7, 2021 |
|
#
?
Mar 7, 2021 11:35
|
|
|
Pile Of Garbage posted:Obviously if you're using the DB on a compromised system you're screwed anyway but that should never dissuade you or anyone practising good security. And because the only way you or I are getting attacked is by a system compromise (evil men in black clothes aren't coming in through your skylight), its a moot point where the keyfile is saved. If the malware is after keypass, it'd be something like - monitor for launch of keepass.exe - observe keystrokes - observe file access, copy recent access - done It literally does not matter if you pulled that file off the desktop or fort knox. Also, no one gaining physical access to your machine is going to care to hunt for your keyfile manually, because they need your password as well. And because physical access = complete access = admin level malware = the exact scenario above. I'd even argue that if the attacker is say, an abusive spouse, then they're going to be more likely to know where the keyfile is if it's in a safe than just an arbitrary file on the disk and be able to socially engineer access to that easier than they'd find the right file without specialist IT knowledge. KP's best practices are not wrong, they're just speaking about a threat model that's not applicable here and it also assumes other mitigation strategies are being used before where the file physically is kept, matters at all. In such cases its also not a keyfile you want to use, because mitigation against having that file copied on-read is always insufficient or prohibitively invasive. You would use something where the physical location of the item does matter, e.g. a Yubikey. e: I'd point out as much as they do talk about how to use a keyfile, they also don't even go so far as to suggest it as a default option. They know it's security theatre that's orders of magnitude more likely to get someone locked out of a vault than keep someone out.
|
|
#
?
Mar 7, 2021 12:34
|
|
|
Keyfiles are to make vault access easier because you don't have to type a password, not more secure because ~reasons~
|
|
#
?
Mar 7, 2021 17:38
|
|
|
Getting back to the passphrases debate, I did a bit more reading around on the subject of length. Arnold Reinhold created the Diceware method and his recommendations at least last year was 6 words and the EFF say the same (in a single word, search for "six"). Keepass' generator also indicated the something similar and gave entropy calculations, 5 words being rated "weak" 64.62 bit entropy but 6 being rated "good" with 77.55. My link above disagrees, stating 5 was "strong" with 72.78 bits entropy. Naturally I'm now facing another bloody password change if I've unintentionally not gone far enough. Admittedly my offline Keepass database of recovery methods has a longer passphrase, but do I need to crank it all up even further?
|
|
#
?
Mar 10, 2021 06:21
|
|
|
Rooted Vegetable posted:Getting back to the passphrases debate, I did a bit more reading around on the subject of length. something I discovered cranked my passphrase difficulty up was using actual punctuation in it. Its a sentence, write it out like one.
|
|
#
?
Mar 10, 2021 06:44
|
|
|
If it's a sentence then it's not high entropy at all. Using special characters or punctuation greatly increases the user's cognitive load for negligible entropy gain. If entropy is not enough, and another word to an alphabetic, lowercase only diceware passphrase instead of increasing the likelihood of misremembering or stumbling into keyboard character encoding issues when emergency unlocking. 80+ bits is enough forever, no one will ever brute force that, nor will anyone bother to try it when other things are so much easier.
|
|
#
?
Mar 10, 2021 12:38
|
|
|
Storm One posted:80+ bits is enough forever, no one will ever brute force that, nor will anyone bother to try it when other things are so much easier. >=80bits would be seven random words according to KeepassXC...? Storm One posted:. Yep that's what you're saying. Off to generate words... RFC2324 posted:something I discovered cranked my passphrase difficulty up was using actual punctuation in it. Its a sentence, write it out like one. I think she means like a sentence, but not an actual sentence. E.g. "Correct, Horse Battery Staple." Rooted Vegetable fucked around with this message at 17:37 on Mar 10, 2021 |
|
#
?
Mar 10, 2021 15:12
|
|
|
Rooted Vegetable posted:>=80bits would be seven random words according to KeepassXC...? She, and basically. If you are considering a string of random words to be a phrase, then you can add punctuation and call it a sentence.
|
|
#
?
Mar 10, 2021 17:31
|
|
|
|
| # ? May 24, 2024 22:27 |
|
|
Rooted Vegetable posted:I think she means like a sentence, but not an actual sentence. E.g. "Correct, Horse Battery Staple." Sure, but the point stands, unless you're confident that: 1) you'll never get confused about what and where the punctuation is, and 2) you'll never type your passphrase in a different locale than your current one (do you know where the comma and question mark keys are in a french keyboard layout?) are both true, then you're better off rejecting any characters other than lowercase ASCII letters in your master password.
|
|
#
?
Mar 10, 2021 22:23
|
|