/gee/...

That's pretty clever. I like that idea.

It's simple, elegant, and can be implemented in an infinite number of ways given there are a theoretical infinite number of sentences that can generated by English.

wrong, a cracking program could still guess that. hybrid attacks are becoming dangerous because if thinking like this

Use memes. :^)

REEEEEEEEE!!!!!InstallGentoodid9/11

point to a pastebin with a password like this cracked please (5+words 5+random). this interests me

The fact that it lists an 8 digit password as strong invalidates the graphic.

Just write short sentences for passwords.

For instance my wifi is: ihopethisfuckinthingworks

Paper and pens exist, you know. Your paper can't be held hostage by the mill or tree logger.

I made a random number generator for this. Good luck.

even if you have a Cred Forums pass, such a deliberately stupid post couldn't have been worth it. could it?

>Stringed together dictionary works

An elementary school student with a GTX 470 and Hashcat is going to break that in an hour.

>Shitlord! Paper in [CURRENT YEAR]?!

correct horse battery staple is certainly secure as long as the terms are randomly chosen from a big enough list(which any dictionary is)
1 word = 1 in 1,000 , trivial to guess
2 words = 1 in 1,000,000 easy to guess
3 words = 1 in 1,000,000,000 still relatively easy to guess
4 words = 1 in 1,000,000,000,000
that's 1 trillion combinations of 4 random words.
That's unlikely to get guesed
but if you want to be 100% sure, just go with 5 words.
10^15 combinations is more than enough.

en.wikipedia.org/wiki/Diceware

I think yall are seriously underrating dictionary attacks.

That image is complete bullshit.

Who the fuck put together such an awful 'guide'? That is insulting and very wrong.

they just forget to tell the crackers that it's a secure password and they need to respect that :^)
pic related are cracked passwords
dictionary attacks work great against words and other guessable shit, the math in assumes the attacker knows that you're using random words from a dictionary, and has the same dictionary(which is too optimistic, the attackers dictionary will be bigger than yours). for 4 random words the dictionary would have to be at least 6 TB, but this is very optimistic for the attacker, in reality size could easily be 2-3x that.
But we've been assuming we chose from a list of 1000 words, which is fairly small. If we use a 2k word list instead(still only fairly common words) it becomes 96 TB... for a 3k word list the dictionary becomes ~500 TB.
Also, dictionarys are completely useless against salted passwords(salts exist to make dictionaries useless)

F.K,*7A(&&Cx@D8qd@,W
How safe is this type of password?

Generally speaking yeah anyone who's using bcrypt and/or hard salting that shit will make it incredibly difficult to crack.

I'm not really hip on the dict maths but assuming uncompressed ascii-only pure english words under lets say a generous 10 characters, that's probly going to be

waifu+year you were born+favorite pokemon+unique symbol

literally uncrackable

whats salt?

some constant known to your crypto function that pads arbitrary data onto all passwords for storage. Like if your password was prepended by the date of your account creation before hashing just to make it cryptographically stronger.

>/gee/, what are some good methods and ideas of generating a secure password that isn't a 20+ string of random characters and is easy to remember?
I have thought about this exact question a great deal, and have a good understanding of how password cracking and account leaks work in the real world.

The general idea is to balance memorization cost and password security. In other words, to pick a secure-but-memorizable password you need to optimize your scheme for “bits per effort”. Of course, this is hard to do mathematically because we don't have a good idea of how to define ‘memorization effort’.

The best advice in practice seems to be using diceware/correcthorse-style passwords, because they're very easy to memorize for the amount of entropy they give.

I hope that answers the basics of your question. If you want me to go into more detail, I could dig up some old posts on Cred Forums where I did so in great depth.

Also, the same general principles apply:

1. Never reuse passwords for different services. Ideally, use fully random passwords for individual acounts.

2. Use a password manager. It trivializes #1. Back the password database up in multiple locations.

3. Make sure to pick enough words for your master passwords. The correct horse battery scheme is very, very susceptible to “too short” passwords. I wouldn't even use 4 words. I personally use 8 words out of a dictionary of 1000, but I also reorder them to make more sense in my head. (This is about equivalent to 7 fully random words, but lets me form a better mental picture)

hth

Also, using a good PBKDF for your master password can make your passwords many orders of magnitude stronger than it would otherwise be. For websites you basically can't control this, but if you're using a local password manager (as I recommend) you can.

With pass/GnuPG, it's controlled in ~/.gnupg/gpg.conf. I use these settings myself:

s2k-mode 3
s2k-cipher-algo aes256
s2k-digest-algo sha512
s2k-count 65011712

This takes a few seconds to decrypt on my 3.3 GHz SB-E processor, but in turn will make your passphrase nigh unassailable (computationally) against even against global adversaries.

(Of course, the elephant in the room is that GnuPG is susceptible to quantum computational attacks, but since GnuPG is future-proof that's easily rectified once a post-quantum encryption scheme makes its way into GnuPG)

I just use Keepass, OP

No I don't use the autoupdater that could be man-in-the-middle attacked either.

Why remember when you can have something do it for you

but how would that work against a dictionary attack?

Honestly I dont get how making stuff even more encrypted is an issue right now when we cant even crack it beyond a certain point. Wouldnt it take the same amount of attempts regardless of encryption method

Is it stupid to put your password DB on a cloud service? Assuming you use a strong password + keyfile, it'd be impossible to get into, right?
I wanna be able to sync shit across my devices easily and that seems the easiest easy.

Salt defends against the password entry/hash.

If you're not given a password but rather a list of hashes you don't KNOW the salt, thats a ton more entropy if every 1password1 is prefixed with some 10 number date information

Is there a password database program that can generate random word combinations for me?

do you know what a hash function is?
>pastebin
nobody uses pastebin for real password lists, big password lists can certainly get into the gigabytes. I have no idea where pastebins limit is but i doubt it's over 10 MB.
Also, most text editors can't handle textfiles with millions of lines.
Alright so your sentence is 30 characters, that means ~30 bits of entropy[1], which is approximately 10^9 combinations(a billion).
by itself, that's weak, and this is evident in sentences getting cracked[2]. However you added 2 random characters(and 2 punctuation chracters at the end of the sentence, but those are trivial) which makes it ~1000 harder to crack.
Could be cracked, but not that likely i'd say, but it's hard to judge anything but simple password schemes.

[1]for the math on this, see what-if.xkcd.com/34/
[2]i can get more exercepts from my list with sentences that got cracked if you want.

>but how would that work against a dictionary attack?
Depends on what you mean by dictionary. To be precise, tt helps against the following:

1. Rainbow table attacks
2. Hash cross-comparison
3. Whole-database password cracking

#1 is when you have an existing, perhaps large database of known password hash combinations which are indexed (efficiently searchable) by their hash. You can build such a large-scale database over time and apply it to any given leaked hash to get the password it corresponds to.

#2 is when you have a big leak of accounts+hashes. If you see that the same hash comes up multiple times, you know that it's going to be a more common password (rather than a rarer one). In particular, if you know the passwords of some accounts (e.g. say user “bob” in your target database has re-used his password on a different site for which you have the plaintext passwords), then you also know the password for everybody else with the same hash.

#3 is when you have a big collection of accounts and you just want to crack “some” account (rather than any specific account). If they're unsalted, then you can compare every password attempt against every single account simultaneously, which is very efficiently doable (compared to having to try them one by one).

Note that #2 and #3 are only defeated by using unique salts per user. #1 is also defeated by using a single global salt (e.g. like Cred Forums's secure captcha).

get random words
translate some into a different languages you know
insert random symbols anywhere

thequi-ckkahve&rengitilkizıp*larover+

literally uncrackable unless they specifically target you
and very strong even when they do target you

forgot image

Depends on several factors:

1. How much do you trust your cryptography?
2. If the cloud service suddenly deleted your data, how bad would it be for you?
3. Does your password database leak any metadata you care about (e.g. names of accounts, number of passwords, how often you change passwords, etc.)?

If you trust your cryptography highly and don't mind leaking a bit of metadata (in exchange for the benefits), I would say feel free.

If you don't trust your cryptography, switch to a password manager you can trust.

>do you know what a hash function is?
i dont really. I know i should research instead of ask though, but Cred Forums has always been good at layman explanations

oh that makes sense just checking the hash. now i see why salt is useful, so that you cant check the hash right

>That feeling of wanting to know if you have my password but can't ask for obvious reasons

Oh, also - there's something I really, really, *really* want to stress: Entropy is not a function of your password. Entropy is a function of your password generation scheme.

“correct horse battery staple” is a good example of this. If you just go ahead and use that password for all your accounts, you'll have 0 bits of entropy.

Why? Because you're reusing the password across every single site. It's fully predictable, there's no random factor involved whatsoever. It doesn't matter whether your password is “correct horse battery staple” or “e1TP1bDRZpWdXWYgqu8bla17koSFVrE9” if you reuse it (or reuse a similar password).

Entropy comes from the *unpredictability* of your passwords, as measured by the likelihood of me predicting your password for site Z when given your passwords for sites A, B, C, D ... X and Y.

The question you have to ask yourself: Assuming an adversary can see all of my passwords except this one, how likely are they to guess it? If you do some dumb shit like “” for every website, that would very clearly be trivial.

This is also why any website that rates your “password strength” is defective by design. It's impossible to do, because it simply cannot know how unpredictable your passwords actually are given only one of them.

make another one according to your scheme, or describe your scheme here.

That's measured on an ideal completely compromised level. If someone has a SEPARATE HASH of every password you've ever entered that's still going to have a good amount of entropy, reuse can just turn that into none in an instant.

is correcthorsebatterystaple on that list?

Its meme enough for some idiot to use it

also even some hash list without identifying user information would have a BIT of entropy if they KNOW your password is in it.

>That's measured on an ideal completely compromised level.
I'm measuring in terms of practical, real-world assumptions.

In the real world, password databases get leaked. I have many gigabytes of plaintext passwords on my hard drive, and it looks like does too.

You can assume that I know your cleartext passwords for _some_ websites, and am trying to break into your high-value accounts based on that information.

I've always taken two passwords, chopped them in half, then strung them together with special characters and a number on the end (or in front, or not at all depending on what the halves end up being)
No idea how secure it is

Sure, I'm not saying that reusing a password is safe. Offer some free service and you get your own brand new list of logins and cleartext passwords no hax required.

My passwords come from serial numbers and bar codes of trash, then alpha+special'd, then usually add a random word or two that are maybe within a 1000 word dict range?

My autism can take it.

I have a tiered system. Emails, get a random string and 2 step verification is a plus. Everything else, has more or less the same password. Am I fucked?

Use a password manager, use tarsnap to back up your password manager master key. Problem solved.

>tarsnap
Do you use tarsnap? Would you mind answering a question for me, that I can't see explained anywhere on their website?

Is their encryption client-side or server-side. Similarly, is their deduplication client-side or server-side?

using a PBKDF is a great idea
also, key-based authentication is amazing for things that support it
...surprisingly not
i checked and i got the list in 2012, the correct horse battery staple
the xkcd comic was published in 2011. The list is likely composed from passwords used before the comic was published, which would explain why it's not there.
very secure

Diceware
>world.std.com/~reinhold/diceware.html
People saying to have a phrase is bad advice, natural correct grammar reduces the entropy, and humans are generally bad at generating randomness. The words should be random.