Why not just use two passwords

I can't figure it out Holla Forums.
Everything would be so much safer form brute force attacks if people had to use 2 passwords instead of a "Name"(which is often shown to everyone) and a password(Which is only 1 line they have to bruteforce).
They would only allow access if you guessed 1 password right, and it wouldn't tell you if the first or the second password was the one that failed.

Example in 2nd image.
Bruteforcing would be *infinitely* harder because you would have to guess both passwords, simultaneously. You need to go to social engineering now because to bruteforce it you either have to guess the same passwords for both squares(IE: You can only bruteforce the password of retards) or you have to bruteforce ALL the possibilities for the first password to see if your guess of the 2nd password is correct.

How come nobody has thought of this? better than being locked out of my account for 1 hour so I can try to log in again.

Other urls found in this thread:

passwordstore.org/
msdn.microsoft.com/en-us/library/windows/desktop/microsoft.directx_sdk.idirectinputdevice8.idirectinputdevice8.setcooperativelevel(v=vs.85).aspx
twitter.com/AnonBabble

The mockup.
It doesn't tell much I know.

This is (almost) equivalent to making your password twice as long. Just take your two passwords and concatenate them. Same effect. They can't tell which half of the password they got wrong.

For proper password safety use a password manager like KeepassX. That way you can use really long unique passwords.

OP is on to something here.

OP have you not heard of 2 factor authentication or something?
It's pretty damn secure as long as your phone isn't compromised too.

Because standard/average users would not want to input two passwords. It is too much of a hassle for them and would appear to give very little benefit.
Alternatively: why can't usernames be hidden as they are typed, similarly to passwords?

Thinking about it, this system is already in rotation and I just didn't realize it. Seeing made me realize it.
Some websites never show the username used in the login ever again, instead making you choose another "public" username sometime in the future. This means that the same thing I said is already in rotation. This has the bonus of not making people think "Why the fuck do I have to insert my password twice?"
If the login usernames were blanked out with **** like passwords then it would be pretty much the same.

This thread is pretty much solved I guess.

Everything would be much safer if everyone used 5 passwords instead of two! Or how about 10? Or 20? The only way to be truly secure is to use 5 different 250 character passwords!

This is where your argument falls apart.

You could have a thousand passwords, it doesn't matter if your traffic gets intercepted.

is right, this is pretty much exactly the fucking same as making 1 password but twice as long. In fact, having 1 password that's twice as long is MORE secure.

What happens when the database is hacked, and some chinks have a copy of your password hashes? If you have 2 passwords of length n, then they can bruteforce half of your security at a time. If you have one password of length 2n, they can only bruteforce the entire thing at once, so it takes a lot longer.

Where n = 5 (for example)
26^5 + 26^5 = 2376275226^10 = 141167095653376

No, he really isn't. Two factor authentication is using 2 different forms of authentication. What the OP proposed is fucking stupid. Pick 2 out of:
1. Something the user has
2. Something the user knows
3. Something the user is

This is a much better way to handle authentication

assuming that your TLS/SSL connection is not man in the middled.

2nd factor authentication works.

using 2 passwords is complex and inconvenient to remember.

Using an inconvenient QR code and time based code generator + whatever long password(s) you pick offers a better security stand point when it comes to authentication both physical and logical control of authentication.

I'm not surprised a lot of main stream normie sites like google, amazon, facebook have used this type of 2 factor auth because they are the ONLY ones that want access to your data.

However I am surprised that certain FOSS sites eg. GNUstatus aka GNUsocial does not seem to support 2 factor auth.


Using two passwords as other have posted, it just as good as using a longer password. That is assuming you do not have an autistic website that requires you to have certain stupid password requirements. (eg. 8 chars in length, 1 cap, 1 number or a site that uses SHA1 still)

only until the website is compromised, at which point it becomes exponentially weaker compared to 1 password, as the password length increases. As long as my calculation was right anyway

Why not just make your password twice as long?

well in that case obviously any method of authentication might as well as be thrown out the window.

Well, ideally your password should be strong enough that it remains safe even in the event of someone nefarious obtaining a salted+hashed version. That's easier if you have one double-length password rather than 2 normal-length ones.

On all of my local machines I use a ~40 char password. I like having a password that's well beyond the point of being strong enough that it doesn't even matter if someone finds out the hash. Obviously the best scenario is it nobody finds the hash, but it's good practice to plan for failure

OP, my technique is similar to this. Because I don't want to risk one service getting hacked and the password hash bruteforced, I have a Hashing Application that takes:
1. Master Password
2. Service Name

... and generates a hash combining the two. This way, the password used for each service is different.

Pic related. Upon clicking okay, the resulting hash goes to the clipboard (for easy Ctrl+V'ing into password field) and the program shuts.

passwordstore.org/

Nope. Services that give a shit about security store salted hashes.

When you register with "password" as password, they throw it through a hashing function to turn it into "5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8". There is no easy way to find out what the original password was if you only have the hash. The most you can do is try passwords until you find one that gives the same hash.

When you log in it hashes the password you try to log in with and compares that to the stored hash.

If your password is somewhat common or short there are large databases of hashes it might be in. To make those databases useless you can salt the hashes by adding a fixed key (the salt) on top of the password before hashing it. That salt could be another string like "e3c33e889e0e1b62cb7f65c63b60c42bd77275d0e730432fc37b7e624b09ad1f". So when you register with "password" as your password it turns that into "passworde3c33e889e0e1b62cb7f65c63b60c42bd77275d0e730432fc37b7e624b09ad1f" and then hashes that, turning it into "fd3d4b158ac5421dcfd2668e29efa54d901cf1b61701aaf48a6ee57f5cbb4ee0".

If the hackers know the salt and the hashes they would still have to try hashing passwords with that salt to find out that your password is "password". If your password is strong enough brute forcing it that way is practically impossible.

This is the worst auth scheme that for some reason many people recommend. If someone has your password hash for some site and knows you use hashpass (because you seem to just tell people this), they can guess the service name is the site name and then brute force your master password which will compromise all of your accounts. It's almost no better than using the same password on all sites as the only added difficulty is the attacker knowing you use hashpass.

If they really cared they'd store it plain text.
If it's stored as a hash, they can't easily change what algorithm is used to authenticate you. Over time this leads to old and shit algorithms being used on you specifically, like all the md5 hashes still live on sites that have since moved on and transparently supported by crypt(), and how weak SRP groups are still used on your WoW password unless you've changed it recently, or having to force you to enter your plain text password again for re-hashing which defeats the point of avoiding handling your password in plain text.
If you can't keep a single user/pass table secure you don't give a shit about security, anyway.

So all you need is a master password which is too long to be bruteforced, ez


the point is to avoid storing it in plaintext

But that's wrong, you gigantic retard. On next successful login, take the password they submitted and rehash and restore.

If you cared about security, you'd not design systems that send the plain text password. Your "solution" is only possible in systems designed by retards that look like a bank vault with a screen door - super strong cryptographic hashing to prevent password exposure on the server on a site that transmits the password in plain text to the server on every login. Don't be that guy.

When you say "plain text", what exactly are you referring to? There is nothing wrong with hashing server-side, as long as you are using https

There are two server-side ways to steal a password, hack the database or hack the webserver. You security gurus seem to be terrified of transmitting plain text passwords across the database but perfectly ok with transmitting plain text passwords across the webserver. They're both equally retarded. The plain text password should not be transmitted after account creation. This is more difficult to ensure with webshit than real client-server software as you have to think carefully about what happens if files are replaced but it's possible.

Yes, and the database being hacked is a bigger deal because it contains everyone's passwords. If you hack the server, you can only steal passwords of the people currently logging in, and only until you get noticed.

just take five dictionary words and lay them end to end with a few random capital letters

bam, your password is safe from skiddie tools

Are you me? Chuck some numbers in there too, and you're golden.

I don't think it's that easy. If you hash to one round - maybe.

But at the moment, it does ~65,536 (2^16) rounds which makes it pretty darn difficult to crack.

clipboard is open memory that can be accessed freely by any program and it would not be detected as suspicious activity unlike keylogging

FUCKING GENIUS

woah

my mind

is like

fucking BLOWN

Now it all makes sense, retards whining about shills are not mentally ill, just brain damaged (i.e. their brain has shrunk) from a vegan diet lacking in vitamin D, vitamin B12, and omega-3 fats.

So sad, but I guess you have only yourself to blame for your brain damage.

You are wrong.
The solution is simple:


The only drawback is that users would first need to enter login, load page, then password. But can be done with javascript/ajax.


How can keylogging be detected?
All you need is to use keyboard with DirectInput using DISCL_BACKGROUND flag msdn.microsoft.com/en-us/library/windows/desktop/microsoft.directx_sdk.idirectinputdevice8.idirectinputdevice8.setcooperativelevel(v=vs.85).aspx

So you discourage use of password managers?

From what I know, modern browsers allows javascript on websites to copy your clipboard and send back to server with ajax... I don't know if the browser and tab need to be activated...
I think they can't do same with keyboard, or can they?

The guy is on Linux, dunno why you're linking to msdn

Alright you faggots, let me teach you how web server password security should be handled because only one person in the thread seems to have a slight idea of how it works.

Most people around here seem to confuse the concepts of salt and pepper. Salt is a dynamic hash generated on password/user registration that is unique to every user, while pepper is a hash generated on database/software configuration that is shared amongst all users. You may think this is stupid or redundant, but it makes a lot of sense, and it is so basic it's hard to understand why some multimillion companies still don't implement stuff like this.

Salting enhances inner security. If the database is leaked, along with its passwords and their salts (and the hashing algorithm, of course), crackers wouldn't be able to just bruteforce stuff and see if it matches any of the entries of the database; instead, they would have to try to bruteforce each entry of the database by mixing their generated random string with every user's salt and check for matches. This is incredibly more computationally expensive, so much your average skid won't go through the effort of even trying. In addition, even if two users happen to use the same password, this method would make it less obvious, since their access hash would be radically different.

Pepper enhances inter-site security in case of lack of salt. While it can be used in combination with salt, salt is usually a better solution since it covers pepper's use case and more. Basically, pepper can prevent premade rainbow tables or passwords cracked on other sites, since even if two users from different sites use the same password, their hash will always show up different. There is no harm in using salt and pepper together, but it's redundant. Note that in some specific configurations, you may want to use pepper on your webpage scripts to avoid the database from ever reading the original password, just in case it gets compromised.

Second, you will probably want to host website data separate from password data. This is somewhat more complicated than just adding a salt (seriously, programming salting code is braindead, so just do it you faggots), but can mitigate a lot of damage. If possible, store passwords and other really sensitive information on another machine (in the same LAN or even physical machine, if you don't trust crypto enough), and then control access between the two. The passwords machine should only be able to communicate with the main machine, and nothing should ever really leave that machine: don't return the password hashes, just a login token or some error code in case the verification went wrong, or even something as simple as true/false could work as well. Control all access to this machine like you didn't even want to log into it yourself (you will obviously have to for maintenance purposes in case something goes wrong, but try to avoid it as much as you can). Port knocking, two-factor authentication, separate SSH key, local-only access... anything goes.

Now, web page security will always have a weak point, and that's the connection between the client and the (perhaps compromised) server. Basically, there is no sane way to prevent the server from knowing your plaintext password without having the client do some work on his own (using a password manager that can hash the password) or by sending executable JavaScript code to the browser. It would be interesting if browsers had an option to send passwords salted and hashed with, for example, the service name or a pepper hash provided by the website. I can understand why this is not the case, since any change to any of these would fuck up the hash, but it could prevent a malicious website or connection from knowing your password and associating it to other websites in which you use the same username or email. Could be implemented on future HTML versions, but I doubt it since these people are usually not worried about security.

That said, if you are programming your own application, you may as well do this on the client side. It costs nothing, and it helps your clients who use the same password for all sites keep your security.

Keyloggers are a pain in the arse, but Wayland is looking to prevent them, at least the userland level ones. Basically, only root-registered applications may listen on keypresses outside of the focused window.

No, it is actually not a bad idea. It doesn't prevent particular attacks (on the same level as sharing a password across all sites), but it helps preventing malicious or compromised servers from knowing your master password. Basically, your assumptions are only valid in case a private investigator or the NSA (which has better methods to find your passwords, anyway) are behind you. Most of the time, passwords are mass-mined after a database dump, and a successful bruteforcing would only give them a hash valid for that specific website they just hacked.


I wonder if whoever made this post was serious or just pretending.

Never, EVER store plaintext passwords. They will be there when crackers access your server. Even if they happen to be in an airtighted server (how would you handle password changes without at least storing them in plaintext on your main server for a short while until synchronization?), it's still a violation of your clients' privacy. It's better to have an outdated, vulnerable hash that will eventually be updated on next login. You don't even need to do 's JavaScript-dependant solution, just implement a condition in your login code for users whose last login is before the hash algorithm update. It will be sent on plaintext to the server, but at least text based browsers or NoScript users will be able to access your site.

i would use keepassx, but its on qt

So?

i dont like qt, useless bloat.... you can finish stuff with GTK+ without all that qtcore and stuff

btw is there alternative, but on gtk?

How is it bad enough to stop you from using a program? Are you sure you're not just suffering from terminal autism?

Wow! What else do you plan to do with your hard drive that you do nothing with user?

Even so, if you do a significant number of rounds for the hash it makes it pretty difficult to brute force. At present, the HashPass app I made is set to do ~65,000 (whatever 2^16 is) rounds, so even a Private Investigator would have difficulty cracking it. NSA, I imagine, would easily have the resources.

Someone pointed out the "clipboard problem" which is a valid concern imo. But, that criticism could be leveraged against many other password managers (I think it also assumes that your system is compromised - in which case you're fucked anyway).

...

Use pass. It stores everything with existing properly-designed tools that already have GUIs in any toolkit you could possibly want (or none).

Most of the time passwords are grabbed by social engineering/phishing/keylogging so it would be utterly pointless aside from brute force which I don't think is used for getting into online accounts as much as the other methods listed.

All my passwords are created when I'm fucking shitfaced and are just a string of incredibly complex slurs usually about 40-50 characters long.

After I write it I save it to a word file

its not only HDD, its complete resource usage, look at this, in order to install keepassx i neet to install also: qtchooser, eselect-qtgraphicssystem, qtcore!, qtranslations, qttest, qtscript, qtgui.... and then keepassx... what the fuck.. and btw those packages are not small, not all of them.. a system without systemd, pulseaudio, kde, qt, java and selinux are pure gold

thanks user!

disgusting, 0/10. If you're going to save it to your computer, don't use a proprietary format. Best thing you could do though is to physically write it down with a pen and paper, so any malware on your PC cannot read your password list

what if he encrypts password file user?

Sorry I meant .bat file not word file

It's already been invented.

Bruteforcing hasn't been a thing since the 3 failed attempt lockout came along.

...

Stop being retarded, this isn't an argument about minimum wage. That argument doesn't really apply.

...

why not use 3 passwords for even more security?

...

I calculated the maximum necessary tries of a successful dictionary attack on a three lowercase words password with no special symbols versus a 28 characters password using all printable ASCII characters. The 28 chars password is actually harder to guess; marginally, but still harder.

Basically, the only argument against those passwords is "but remembering them is haaaaaaaard", as expected from retards like Randall or the people who think his shitty strips are enlightening in any way.

Now do it with 3 words, with one letter changed to be uppercase, and one number placed randomly. Easy to remember, long, and safe against dictionary attacks

Why does anyone make passwords any other way?

wew lad, this guy has never tried to attack something through the wire, has he?

I always thought he was kind of a poser.

He lost his shit years ago

About the same time he wouldn't shut the hell up about cancer.

In skimming through his recent stuff when I grabbed that other picture, I also noticed that he's got some weird kind of femminist imagination play going on. It seems like all the males in his latest stuff are making really stupid decisions and the females are playing the hero or making the intelligent observations.

Pics related are 3 of the last four.

He's always rotated "protagonist" between females and males in his comics, males being dumbasses or females being clever in his comics is nothing new.

This appears to be consistant, though.

He's been doing that since the beginning.
What I'm noticing lately he's been doing pretty much the same joke over and over. 80% of his comics fall into like 5 very specific categories.