Advanced Password Security - WhatPassword

[FelipeAquinoBr]

Hello, I am an amateur developer and everything I think might be a problem I try to solve by programming. Last month a friend mentioned that ETH wallets have low security with a password. So I made a prototype of a system that makes the password difficult and it is always unique. I'll explain how it works and have the project practically done.

What is WhatPassword?
It is a site or app that creates a 2Fa password to log into other sites or app.

How are passwords created?
The passwords are created in 5 different parts and the join makes the WhatPassword.

Part 1 - Prefix = WP?
Part 2 - Entered by the user = med2
Part 3 - Posted by E-mail = 1Los90
Part 4 - Sent by SMS = 3426
Part 5 - Word generated while creating password = love

WhatPassword = WP?med21Los903426love

Illustrative picture


OK, I know it seems too long the password and very complicated to type all this quickly. That's why each generated WP is only valid for 1 minute.

All passwords are sent or displayed to the user before going to the database and when it is saved in the database is already encrypted, this will not cause problems if the server is invaded.

I believe I can further decrease the password size and maintain the high security standard. Logic that the prefix will not be typed because it will be put on the form automatically.

Illustrative image of sending and access.


I would like to know your opinion about the prototype, of course it seems to have nothing to do with crypto-coins, but there is a lot to be. In addition you protect crypto-coin sites and you can also use the WhatPassword a paid tool. Because sending SMS has a high cost, in addition to this system I have explained is ready, I have other factors to add security that I will not divulge yet because the original idea is not completely copied.



edit
----

I remembered to mention a new idea I had about password security.
This idea may be more viable, create a token-like device that generates a password for the user, but the password is only generated if the user is going through 2 security parameters.

By holding the device in his hand, he would have to go through the biometric and facial reader at the same time to create a password.

This project is logically expensive, it would also be nice to put another heart attack on this device, if the person is assaulted and forced to create a password, this would be blocked unless it is very calm during a robbery kkk I find it difficult .

I have lots of ideas and few friends to share.

[1714118575]

1714118575

[1714118575]

1714118575

[o0o0]

seems overly complex.

i heard at a security conference that in pure combination brute forcing a password that mixtures of upper lower etc do little to actually delay a break.

computers dont care whats in a password and the one factor that slows them down is length.

apparently the best password is a long one. as humans we are wired to remember phrases, pictures etc better than complex patterns so the password

iwenttothebeachwithmydogandthrewitastick

is quite a good one. no spaces so computers dont know where a word starts and stops. good luck dictionarying that. something to consider for you. id find remembering your generated passwords complex. people will write them down in a book or notepad file on their pc which defeats the security of it.

note that was in relation to complexity.

your system has pass valid for 1 minute. its overly complex for 1 minute. it could be simplier with brute force not possible in that time

[FelipeAquinoBr]

seems overly complex.

i heard at a security conference that in pure combination brute forcing a password that mixtures of upper lower etc do little to actually delay a break.

computers dont care whats in a password and the one factor that slows them down is length.

apparently the best password is a long one. as humans we are wired to remember phrases, pictures etc better than complex patterns so the password

iwenttothebeachwithmydogandthrewitastick

is quite a good one. no spaces so computers dont know where a word starts and stops. good luck dictionarying that. something to consider for you. id find remembering your generated passwords complex. people will write them down in a book or notepad file on their pc which defeats the security of it.

note that was in relation to complexity.

your system has pass valid for 1 minute. its overly complex for 1 minute. it could be simplier with brute force not possible in that time

Hi friend, your thinking is exactly right. I created the prototype before even studying the complexity of passwords. Then I found this site called How Secure Is My Password? https://howsecureismypassword.net/

It tells you how long it would take to break your password, as in the example I gave up the time is 9 SEXTILLION YEARS ... OK it's safe, but then I read a post from the guy who set the current secure password pattern and he said exactly this, that he regrets having made this password pattern that contains special characters, this is totally false ...

A password in the current safe pattern would be @ AllD0n3! this password would be broken in only 4 WEEKS and makes it very difficult to type these characters and so on.

A simple password to memorize as: bitcoinlitecoin this password would be broken in 1 THOUSAND YEARS.

So I posted this project here for people who want to participate and make it more viable.

[Kakmakr]

seems overly complex.

i heard at a security conference that in pure combination brute forcing a password that mixtures of upper lower etc do little to actually delay a break.

computers dont care whats in a password and the one factor that slows them down is length.

apparently the best password is a long one. as humans we are wired to remember phrases, pictures etc better than complex patterns so the password

iwenttothebeachwithmydogandthrewitastick

is quite a good one. no spaces so computers dont know where a word starts and stops. good luck dictionarying that. something to consider for you. id find remembering your generated passwords complex. people will write them down in a book or notepad file on their pc which defeats the security of it.

note that was in relation to complexity.

your system has pass valid for 1 minute. its overly complex for 1 minute. it could be simplier with brute force not possible in that time

What if the Bruteforce method use a database of words which it looks for within the password. So it dissect the password, by looking for words, even if there are no spaces in between? I like to replace letters with numbers, for example : P@$$w0rd43v3R {Password for ever}-- So there is no recognisable words in that password that can be extracted.

It is still readable by humans, but computers will have a hard time figuring that out.  (And NO, I am not using that password, it was just an example)

[NeuroticFish]

What if the Bruteforce method use a database of words which it looks for within the password. So it dissect the password, by looking for words, even if there are no spaces in between? I like to replace letters with numbers, for example : P@$$w0rd43v3R {Password for ever}-- So there is no recognisable words in that password that can be extracted.

It is still readable by humans, but computers will have a hard time figuring that out.  (And NO, I am not using that password, it was just an example)

I would be very careful with this kind of rules. I've read a few years ago already that some of the more advanced dictionary-based brute force password crackers were starting to handle "leet" variations of the dictionary words.

So I made a prototype of a system that makes the password difficult and it is always unique.

OP, from what I understand the system is a little bit overcomplicated and the website has to implement/use your system, since the password keeps changing.
And if the website wants to improve, there's already 2FA that does the job much easier.

[mocacinno]

--snip--
All passwords are sent or displayed to the user before going to the database and when it is saved in the database is already encrypted, this will not cause problems if the server is invaded.
--snip--

Could you elaborate on the quoted text? Do i understand it correctly if i presume the passwords go into an encrypted database, but they're stored in plain text in this database?
If so, this is a huge security risk, even if your database is encrypted... I'd rather use a system with an unencrypted database that stores a salted hash of my password than using a system with an encrypted database that stores my password in plain text...

[o0o0]

seems overly complex.

i heard at a security conference that in pure combination brute forcing a password that mixtures of upper lower etc do little to actually delay a break.

computers dont care whats in a password and the one factor that slows them down is length.

apparently the best password is a long one. as humans we are wired to remember phrases, pictures etc better than complex patterns so the password

iwenttothebeachwithmydogandthrewitastick

is quite a good one. no spaces so computers dont know where a word starts and stops. good luck dictionarying that. something to consider for you. id find remembering your generated passwords complex. people will write them down in a book or notepad file on their pc which defeats the security of it.

note that was in relation to complexity.

your system has pass valid for 1 minute. its overly complex for 1 minute. it could be simplier with brute force not possible in that time

What if the Bruteforce method use a database of words which it looks for within the password. So it dissect the password, by looking for words, even if there are no spaces in between? I like to replace letters with numbers, for example : P@$$w0rd43v3R {Password for ever}-- So there is no recognisable words in that password that can be extracted.

It is still readable by humans, but computers will have a hard time figuring that out.   (And NO, I am not using that password, it was just an example)

what you say makes no sense...

it doesnt know your password or length. a brute force tries every character as 1..... then does every combo of 2 letters. if it knew my password was x characters how would it know where words stop and start it wouldnt. letters replaced with numbers dont trick computer brute forces... it tricks humans guessing.

COMPUTERS DONT have a hard time with numbers instead of letters. computers dont have brains, souls, reasoning. they do what we tell them to do.

test and t3st is no different to a computer. it will crack them both brute forcing in roughly the same time.

[FelipeAquinoBr]

--snip--
All passwords are sent or displayed to the user before going to the database and when it is saved in the database is already encrypted, this will not cause problems if the server is invaded.
--snip--

Could you elaborate on the quoted text? Do i understand it correctly if i presume the passwords go into an encrypted database, but they're stored in plain text in this database?
If so, this is a huge security risk, even if your database is encrypted... I'd rather use a system with an unencrypted database that stores a salted hash of my password than using a system with an encrypted database that stores my password in plain text...

Hello Friend! The text must have gotten a bit confusing, because it is actually the encrypted password entered in the database and then it will only be decrypted if it has the 5 parts together. Even if a hacker invades the database will not be a risk, because he needs to join the 5 parts in 1 minute and still access the database.

[Betwrong]

seems overly complex.

i heard at a security conference that in pure combination brute forcing a password that mixtures of upper lower etc do little to actually delay a break.

computers dont care whats in a password and the one factor that slows them down is length.

apparently the best password is a long one. as humans we are wired to remember phrases, pictures etc better than complex patterns so the password

iwenttothebeachwithmydogandthrewitastick

is quite a good one. no spaces so computers dont know where a word starts and stops. good luck dictionarying that. something to consider for you. id find remembering your generated passwords complex. people will write them down in a book or notepad file on their pc which defeats the security of it.

note that was in relation to complexity.

your system has pass valid for 1 minute. its overly complex for 1 minute. it could be simplier with brute force not possible in that time

What if the Bruteforce method use a database of words which it looks for within the password. So it dissect the password, by looking for words, even if there are no spaces in between? I like to replace letters with numbers, for example : P@$$w0rd43v3R {Password for ever}-- So there is no recognisable words in that password that can be extracted.

It is still readable by humans, but computers will have a hard time figuring that out.   (And NO, I am not using that password, it was just an example)

what you say makes no sense...

it doesnt know your password or length. a brute force tries every character as 1..... then does every combo of 2 letters. if it knew my password was x characters how would it know where words stop and start it wouldnt. letters replaced with numbers dont trick computer brute forces... it tricks humans guessing.

COMPUTERS DONT have a hard time with numbers instead of letters. computers dont have brains, souls, reasoning. they do what we tell them to do.

test and t3st is no different to a computer. it will crack them both brute forcing in roughly the same time.

I thought that in a dictionary-based brute-forcing it makes a big difference. And also I thought that the fist thing a cracker tries is going through all the possible real words because most people use them for passwords and thus using this method can save a lot of time. Was I wrong? Do they no longer use a dictionary-based brute-forcing?

[mocacinno]

--snip--

Hello Friend! The text must have gotten a bit confusing, because it is actually the encrypted password entered in the database and then it will only be decrypted if it has the 5 parts together. Even if a hacker invades the database will not be a risk, because he needs to join the 5 parts in 1 minute and still access the database.

I've been writing web applications for my employer for quite a while... I'm not a good scripter/programmer and defenatly a bad designer, but i do know a thing or two about security... Things i've picked up over the years

Let's review 2 situations from a malicious person's view:
Situation A: You store your passwords, chopped in 5 pieces and encrypted into a database

• Would it be imaginable you wrote a single bug somewhere in either your code or your webpages? An attack vector you didn't think about? A misconfiguration of your apache/nginx/lighthttpd? A misconfiguration in your database installation? A weak OS/db password? An unpatched binary? If so, would it be unimaginable that the attacker could find a backdoor or a sql injection point that allowed him to dump your database, thus getting his hands on all 5 encrypted pieces of all passwords stored in your database?
• If the attacker got his hands on hundreds of chopped up passwords, would it be imaginable that he found the logic in how to decrypt your passwords? I mean, unless you encrypt the pieces using an offline machine, the passphrase or key *would* technically be hardcoded or stored in a database somewhere on an online machine, right? If the password or the logic wasn't stored online, how would you ever encrypt/decrypt the pieces yourself? The same attack vector as the one in step one *could* *potentially* be used to rip your sourcecode to look for the hardcoded password/password logic
• IF an attacker managed to get past the first 2 hurdles, would it be imaginable he could then execute the first step and apply what he learned in the second step and decrypt NEW passwords in a matter of seconds?
• Sure, this is a longshot, but if your service ever becomes *the next big thing*, you should be prepared for really smart evil people investing a lot of time into breaking your security model... So why not build it foolproof from the start?

Situation B: You store your passwords, not chopped but stored as a SALTED hash in your database (for example, bcrypt with a high cost)

• Would it be imaginable you wrote a single bug somewhere in either your code or your webpages? An attack vector you didn't think about? A misconfiguration of your apache/nginx/lighthttpd? A misconfiguration in your database installation? A weak OS/db password? An unpatched binary? If so, would it be unimaginable that the attacker could find a backdoor or a sql injection point that allowed him to dump your database, thus getting his hands on the salted hash?
• Now here is where things get different: even if he dumps all passwords, he needs to brute force each and every one of those passwords starting from 0. Since you have long passwords, and they got salted during the encryption process, there is simply no way he'll ever be able to brute force a single password within any reasonable timeframe

In situation B it doesn't even matter if your complete sourcecode, password file and database dump ever get leaked... The attacker won't be able to use that information to decrypt the password hashes.
As long as there are no rainbow tables for bcrypt passwords with a length of 23-25 characters are generated, your users will always be safe (hint: i don't think such rainbow tables will exist in our lifetime... It would require bcrypt asics and a corporate SAN to generate and store this data)

And from a programming point of view: what's the difference between comparing two plaintext strings and two hashes? The only extra cost is that you have to hash the user's input twice... Costing you a couple processor cycles and maybe a couple miliseconds... Seems like a fair price to protect your users, doesn't it?

[FelipeAquinoBr]

In situation B it doesn't even matter if your complete sourcecode, password file and database dump ever get leaked... The attacker won't be able to use that information to decrypt the password hashes.
As long as there are no rainbow tables for bcrypt passwords with a length of 23-25 characters are generated, your users will always be safe (hint: i don't think such rainbow tables will exist in our lifetime... It would require bcrypt asics and a corporate SAN to generate and store this data)

And from a programming point of view: what's the difference between comparing two plaintext strings and two hashes? The only extra cost is that you have to hash the user's input twice... Costing you a couple processor cycles and maybe a couple miliseconds... Seems like a fair price to protect your users, doesn't it?

Hello, Mocacinno!

Thanks for your comment, I'll give you more detailed information about the encryption and the site. I believe that everything you said will not cause any problems for WhatPassword.

From your two models I'm using B.

I am using the Laravel framework 5.6 for source code structure and this guarantees me a great security against bugs that I myself could cause by creating the source code. About cryptography I'm using bcrypt that already comes included in the framework. Another security factor that I have not yet created but I have already foreseen is the creation of device to send multiple emails and sms when a person requests your password, however only 1 of these are true and the other fakes. So for the hacker to try to know which one is true, it will cost more time and make it almost impossible to do everything in 1 minute.

The passwords in the database are also destroyed after that time, so it does not matter if he hacks the database, it will only have passwords valid for less than 1 minute.

I hope you have explained it clearly. hug

[mocacinno]

--snip--
Hello, Mocacinno!

Thanks for your comment, I'll give you more detailed information about the encryption and the site. I believe that everything you said will not cause any problems for WhatPassword.

From your two models I'm using B.

I am using the Laravel framework 5.6 for source code structure and this guarantees me a great security against bugs that I myself could cause by creating the source code. About cryptography I'm using bcrypt that already comes included in the framework. Another security factor that I have not yet created but I have already foreseen is the creation of device to send multiple emails and sms when a person requests your password, however only 1 of these are true and the other fakes. So for the hacker to try to know which one is true, it will cost more time and make it almost impossible to do everything in 1 minute.

The passwords in the database are also destroyed after that time, so it does not matter if he hacks the database, it will only have passwords valid for less than 1 minute.

I hope you have explained it clearly. hug

I'm glad to hear you hash your passwords instead of encrypting them, i really was under the impression you were using encryption instead of hashing...
You'd be supprised how many times i had arguments with developers about this subject, for some strange reason a lot of devs seems to prefer to put plaintext passwords in databases instead of using a proper hashing algos... A lot of them don't think they'll ever be a victim of a hacker attack, or they simply overestimate their own talent, or underestimate an evildoer...

Good luck with your project