(untitled)

What should have an awesome password? What are the rules to create the most secure password possible?

>>8256 If I have to make a password I have to be able to enter without a database, I do the following: >Take a couple words that are easy to remember, along with numbers (historical events are good since you can look them up in wikipedia, something like 21_10_Battle_of_Trafalgar_Nelsons_Victory_1805) >Now have a sequence of transformations that remain the same for all your passwords for example, capitalizing the second and second to last letter in any word, incrementing each number by 48, and writing every second _ as & and every second & as %, and replacing each e with an ^ and an E with an +. (Now we have 69_58&bAttL^_oF%tRafalgAr_n+lsoNs&vIctoRy_1853. Easy to remember since you use the same transformations and general sequence for every password, long enough, and fairly dictionary attack proof.

>>8256 It depends on your threat model. Assuming you don't know what your threat model is and you don't want to actually think about it, start with the following. If you don't currently use a Password Safe ? How many passwords do you have to remember ? If the number is higher than you want it to be (some people are good at remembering things, and choose a high number like 32 or 50), some people only can remember 10 to 20 things, then reduce that number to 1 by using a Password Safe. In terms of password safes to use or recommend Wikipedia has a list https://en.wikipedia.org/wiki/List_of_password_managers I use and recommend the original Password Safe https://pwsafe.org/ , though I know other people that use KeepassXc https://keepassxc.org/ and other lainons that just use pass https://www.passwordstore.org/. The reason I personally use the original PasswordSafe is because I have read several papers on the security issues regarding Password Managers, and I value the security architecture of my password manager over its usability and I am willing to put up with a few usability bugs for better security. If you use a Password Safe then your Password Safe/s should have an awesome password that you can remember and can type from muscle memory. Similarly any devices that you need to access without a password safe, should have passwords you remember and are able to type from muscle memory. Passwords in the Password Safe are free to be randomly generated 100 or 256 or 512 character strings depending on the platforms database backend supports. If you are looking for a password generator for passwords inside your password safe, then use something like https://passwordsgenerator.net/ or similar local tools like *makepasswd https://www.defora.org/os/project/117/makepasswd * pwgen https://linux.die.net/man/1/pwgen. (though this has fallen out of favour lately, because of predictability) * Alternatives, include openssl, gpg, /dev/urandom and tr , etc If you want generate memorable passwords for your password safe or passwords outside your password safe see * diceware https://github.com/ulif/diceware * xkcdpass https://pypi.org/project/xkcdpass/ * mkpass https://github.com/hackerb9/mkpass Also see https://pages.nist.gov/800-63-3/ and http://world.std.com/~reinhold/diceware.html In terms of other recommendations, you can use dimensionality reduction to map multi-factor authentication (https://en.wikipedia.org/wiki/Multi-factor_authentication) into a single password. For example you can generate a password based on knowledge (something the user and only the user knows), possession (something the user and only the user has), and inherence (something the user and only the user is) and that is more secure than just using something you will remember. If you want to make passwords that are harder to remember but can be recovered using password hints or clues, then there are specific password generation mechanisms for that. If you want to learn about threat models, and how to make one and use it to determine what information is worth protecting and whether that protection should be a password or something else, then see resources like https://people.eecs.berkeley.edu/~daw/teaching/cs261-f12/hws/Introduction_to_Threat_Modeling.pdf https://www.niaia.org/files/uploads/IndividualOPSECandPersonalSecurity-Chesbro(September2017).pdf https://conference.hitb.org/hitbsecconf2012kul/materials/D1T3%20-%20The%20Grugq%20-%20OPSEC%20-%20Because%20jail%20is%20for%20wuftpd.pdf and others

>>8256 >What should have an awesome password? Your LUKS-encrypted usbstick in your pocket, that contains all of your other passwords. >What are the rules to create the most secure password possible? Maximum possible randomness/length/entropy.

>What should have an awesome password? Anything you care about should have a good password. I try to minimize what I have that requires a password. >What are the rules to create the most secure password possible? I write down most of my passwords on a piece of paper that's almost always with me. I use several methods, but for those passwords I need to be able to recall offhand, I write a tiny little program in a language I know as the password. This is nice and simple and not really subject to common attacks because of how different languages are written. That's just something to consider. If I didn't have a good memory and had so many accounts that a piece of paper and my memory alone weren't enough, I'd probably use a password manager. I'd rather shut down and delete accounts than get to that point, though.

>>8256 It depends entirely upon the user case and the security you're looking for. My model, is very straight forward. - If it's a site I don't care about the security of, I will use a weak password with low entropy. This ultimately doesn't mater because even if it gets hacked, I just don't care. - If it's a site I care about, I will use a high entropy password (150+ entropy). I will also enable some sort of 2FA. I don't believe entropy is a valid measure of password strength anymore, but ultimately I pick passwords that are long, memorable and aren't susceptible to social engineering. - Where it's possible, I will use PKI and disable password login. Coincidentally, I don't trust password managers, and I'm afraid that smart cards or other physical password storage options can be lost, stolen or destroyed too easily. My SecOps aren't very good. Hardware-based security is a very lucrative market for enterprise solutions - I'm just not sold on them for consumer solutions. Definitely not sold on hardware security in the cloud, despite it probably being perfectly fine.

>>8256 Let elaborate on how I do it. I have two kinds of passwords: "master passwords" and "passwords". 1. If a resource permits a password of length 32, then my "password" is of a form: ↳ pwgen -sy -1 32 Z9:AI.@d3vDYIIuPAX0omueg*'@LFT3% Else if the resource doesn't support 32-characters long passwords, then my "password" is of a form: ↳ pwgen -sy -1 N Where N is the maximum number of characters allowed. All of these "passwords" are stored together and encrypted by one of the "master password" using AES256 CBC encryption. 2. Master passwords are those, which I actually remember. I try to limit the number of these passwords. Each master password must be 15+ characters and different. I have: - "Master password", which decrypts the "passwords". - "Master password", which decrypts the hard drive (I am using LUKS over LVM) - "Master password", which decrypts the backups (I backup to local and remote storages. File names are obfuscted, encrypted by AES256 CBC). - "Master password" for the remote storage. Master passwords are saved nowhere, except for my head. Hence why they must be easy to remember.

I am also thinking about implementing a hook, which would wipe the system after N unsuccessful LUKS password attempts. N=5 would be fine. Maybe also another hook, which would throw a bogus kernel error message and silently wipe the system in the background in case a "wipe password" is entered. Also I've been contemplating as to whether I need a user password on my personal laptop given the fact that I already have LUKS and a strong LUKS password + a restrictive iptables policy (yes, I have iptables set up on my personal machine, I know that I am behind NAT 95% of the time and this is overkill, but I may be connecting to an insecure network).

>>8319 >contemplating as to whether I need a user password isn't it always just easier for a ransomware to overwrite those files without the need to brute-force a password attack on your user's password

Really any string of characters thats longer than 25 characters is safe. Its too long to be cracked by even quantum computers with todays technology. Just change every month or so Source: I have a bachelors in CS with a focus in security. My prof was super passionate about password lengths

I like to use hyper-obscure quotes that are important to me, such as little passages from my favourite book or strange quotes from my favourite musician. Always with punctuation and capitalization preserved or added.

>>8714 What about dictionary attacks?

I use combinations of non-actual words that exist in my mind and bogus birthdays that I make for my friends

>>8256 https://www.grc.com/passwords.htm A password generator. I guess for the paranoid you'd want to run something similar on your site. Here's my own recipe: You need salt, the domain name, master passphrase, a hashing algorithm, and Base64 or similar to transform binary data into printable ASCII. Salt is high entropy, memorize it. You don't have to type it always, just be able to recreate it, maybe a song lyric. Domain such as example.com, strip off subdomain, i.e., no www because some sites have auth.example.com or similar for login). Master passphrase can be lower entropy, but able to be typed. Now perform SHA256 or better Hashed message authentication (HMAC). This means: function HMAC( key, data ) { key = SHA256( key ); opad = key XOR 0x5C5C...[to length of hash output) ipad = key XOR 0xA6A6....[to length of hash output) return SHA256( SHA256( ipad + data ) + opad ); // opad and ipad ensure key secrecy in returned value. } HMAC (master_pass + salt, domain ) = site specific password in binary. Encode site specific PW binary to Base64. Base64( site_pass ) = password to enter into site. I use a different Base64 alphabet so that it includes more symbols and such. I enter the same password for each site and yet generate a unique password for each domain. If I want to change all PWs I can simply change the salt and keep using the master passphrase. I keep two scripts to generate the PWs, one using older salt (for sites I haven't upgraded password to), and one with newer salt. The algorithm has become more complex over time with newer iterations adding keystretching to make rainbow tables or password cracking even harder in case the site's PW database is compromised. I also have domain specific limitations remembered, such as the minimum requirements for password and max password length. If a site has a max PW length limit they're not following security best practices, not hashing your PW input, storing it in plaintext. I would avoid those sites, but most banks use mainframes and store your password in cleartext within.

>>8716 Im behind 4 languages good luck

>>8716 At 25 characters long dictionary attacks can still take days to years depending on the complexity (are the words commonly seen together, if not going through the millions of words in the english language and trying every combination isnt that much more efficient than a brute force) . But if thats a big concern you can always pick a song thats always stuck in your head and use the first letter of the first 20-25 words.

>>8742 ohmaniloveben123is! How the fuarrrk do you dictionary attack that?

>>8743 hurr durr exactly here is where I wanted to reply. FuG. Bonus: use secret language paskaDDmopoDDkaljaDD >>8716 Here we go

>>8743 So it's improbable but not impossible. It varies greatly on whether or not the hash was gathered in a large breach and is sitting in some dudes cracker with 12,000 other poor bastards, or someone breached your company and needs *your* user/group for some post-ex/whatever. Some places do continual password audits on in-house servers sporting 2+ GPUs. It's prob not gonna happen, but I've seen >12c passwords cracked that are soykaf like: [spoler]ilovehugedicks123[/spoiler] It's just <word><word><word><word><common_suffix> or some other combination of <word>, <?>, and <suffix>. As someone attempting to recover the plaintext, you're gonna wait a LONG time before you *maybe* get that, but there are people who spend a lot of time thinking about rulesets to maximize recovery chances while minimizing time/resources. At the end of the day that's what it boils down to, right? Time and resources which, depending on your threat model and the situation, an adversary can build/use. It also depends on the algo. No one mentioned it, but if you have the same PW in NTLM and bcrypt, I know which one I'm *not* targeting, and what ruleset I'm going to use accordingly for the sake of time. If I don't have two weeks to sit on a few hashes, I'm not going to bother with a comprehensive ruleset. I'm going to look back at my previous attacks and pick the most statistically probable rulesets and wordlists for the complexity I *assume*. I've also seen EA/DA/DBA accounts non-conformant to the organizational policy with stupid passwords like C0mp@nyName2019 or, in one case, "Summer2018"...

>>8765 unpopular opinion, if you manage a DA account and your character is <8c you should be terminated immediately.

>>>8275 a $5 wrench says I could just beat you into giving me that usb stick and passphrase. >since everyone is posting xkcd

>>10380 sorry fat fingered, this was meant for: >>8275

>>10380 Sorry, officer. My dog ate it yesterday.

>>10380 Big problem, I don't have access to the "have something" portion of my server bootup. I only have the "know something". And no, I don't mean I don't have access to the physical machine. I mean I literally cannot boot it up by myself.

>>10380 >a $5 wrench says I could just beat you into giving me that usb stick and passphrase. You can't beat a key out of someone who doesn't know it himself, eg when it's on a yubikey that accidentally get broken.

>>10387 LUKs encrypted usbsticks and Yubikey are 2 entirely different things. >>10382 >Your LUKS-encrypted usbstick in your pocket >in your pocket didn't you just say it's in you pocket? Also, if I'm to the point of beating you with a wrench - I might as well have some courtesy and reach into your pocket.

one should never keep their boot media on premises. under a rock in a waterproof container in a park down the street is miles better than in your fuarrrking pocket.

>>8256 It's easy: 1) Lowercase Character 2) Uppercase Character 3) Special character 4) Kanji character 5) Unregistered unicode character 6) Thesis 7) Idea 8) Beginning 9) Little description of the plot 10) Proof of the idea 11) Second proof of the idea 12) Ending 13) ~desu

>>10811 >Unregistered unicode character honestly i wonder why this isn't a more common recommendation. it's so obvious i have to assume there's a reason why people don't do it. difficulty in typing it wouldn't be an issue if you just had a hotkey setup that switches your keyboard to "password mode" where all the keys are replaced with obscure unicode control sequences and mixed set of foreign language characters. memorizing would be easy since you could just remember an english sentence or something. even if someone knew what you were doing they'd have to crack your key map in addition to the actual password, and the space of all possible unicode characters is massive. even if you're restricted to ascii a simple automatic substitution cipher that just mixes up which keys print which character would totally foil conventional dictionary attacks without making the password any more difficult to memorize.

>>10393 True story a professor once got his laptop stolen with all his research projects on it, the thief actually felt bad about the guy losing years of work so he sent him the HDD back and kept the rest. Had the drive been encrypted this wouldn't have been possible.

>>10915 >the thief actually felt bad That actually warms my heart. He thought he was robbing a rich professor who could easily replace a piece of equipment, not ruining someone's life I suppose.

>>10812 There are two reasons: 1. You might have to type your passwords on a machine that doesn't have that key map. 2. A lot of sites validate their passwords to only be alphanumeric with special characters. Not every server uses UTF-8. If you know you're going to be on your machine anyways, unregistered unicode characters don't offer any security over using random 32+ character alphanumeric passwords with a password manager.

Basically the most secure password would be about 50 characters long, is totally random, contains no common words or phrases, and is selected from all useable characters. Just about every other suggestion here introduces weaknesses that could be exploited in a brute force attack

>>10917 >unregistered unicode characters don't offer any security over using random 32+ character alphanumeric passwords with a password manager. the reason i was wondering about obscure unicode characters is, counterintuitively enough, that it would be easier to type them in on a computer that isn't mine. right now it's straight up impossible for me to access certain accounts when i'm away from my password manager because they're 32 random characters. even if i have it on my phone or whatever they're a nightmare to type in. with unicode i could in theory get the same password strength from fewer characters, and they could be more memorable. even if the keyboard doesn't have them, you can always search them up on wikipedia or whatever and copy-paste. not ideal but perhaps better than either being locked out of your account or choosing a weaker but memorable password for accounts that you occasionally need access to on other computers (like my university login). on the other hand... >Not every server uses UTF-8 this plus the fact that unicode implementations are notoriously buggy seems like reason enough to avoid this approach.

>>8256 head -c 57 /dev/urandom | base64

>>10923 tr -dc '[:print:]' </dev/urandom | head -c 57