Tag Info

New answers tagged

0

Theoretically that is a 'stronger' password against bruteforce methods than just a single catfish. But you also increase other risks: Shoulder surfing - If an attacker spots you typing your password, even 'ca4f1sh!', over and over its pretty east to remember 7ish characters in a logical order and just go home and try accessing your gmail with a few repeated ...


0

Repeating the word "catfish" multiple times would indeed make the password stronger than any single "catfish". Since there is no way to know that you repeated the word or by how many times it has been repeated it stands to reason that the password is indeed strong. As other explanations of the xkcd comic describe, if a random word group were chosen using a ...


0

The problem with picking a password based on any pattern is that, if the attacker knows the pattern, they can then eliminate relatively large numbers of possible passwords they'd otherwise have to test. This is why we advocate for passwords to be randomly-generated as much as possible. The only restrictions you might want to put on the random generation ...


3

Of course any password that is stored in plain text is a bad idea but the location of the file is in /etc/my.cnf so if a remote user had access to that file I think there would be more things to worry about than having your mysql password stolen. On the other hand if you are not the only one who has physical access to the system then you are still safe from ...


1

I am sorry but if they told me they wanted me to plain text my database password I would say "nope". Now I have heard on cPanel servers running phpMyAdmin use that file to install and uninstall Site Software, which I sorta understand, still think it can be done better. I have never placed my DB password in the .my.cnf thats just asking for a simple LFI ...


1

When using a reliable two-factor authentication system, using a less secure password is reasonable. It's still best to use a difficult password generated by a password generator using upper and lower case, numbers, and symbols. But folks who will not do deploy such a secure password; in the case of a service that offers two-factor authentication, those ...


1

You forgot the local physical attack! A long complex password makes shoulder spotting much less likely to succeed. Even if someone stares at my keyboard, he won't get my passwords unless he's Rainman. (cannot comment)


-2

I found a way to have a password for my Keepass vault that is easy to remember but at the same time virtually impossible to break which I named algorithmic passwords. To construct my password, I'm using a python shell. The basis for my password is a power tower which is a form of function that grows incredibly fast with few operations and numbers. For ...


3

While it is safer to make complicated passwords, I always recommend making them easy at the same time, and also have a uniqueness per website. The only way this would be a vulnerability is if you fall for a phishing scam, which is why it is important to have multiple ways to recover your email address, because your email is your way to recover other ...


4

Using a complex password for a single secure site is like using a special lock on your apartment door, which makes opening the door take longer and protects you better from 1% of all burglars Most answers deal with all kinds of attack scenarios, which could compromise your password, but to decide if a smaller password (6 Characters) is sufficient if you use ...


2

I do very similar, and the way I see it there are two major potential points of failure and I don't really have a good solution for one of them. First major risk is that LastPass itself is hacked and it's data dumped. While data is encrypted locally, my password used to encrypt that data is not very strong. LastPass has recognized that entering in a strong ...


4

There are issues with a couple of your assumptions. 309 million is a laughably small number if there is an offline attack. And on an offline attack, even with a good salt, the attacker will go after the low hanging fruit first. Ie. find the passwords that are in the dictionary, then the short passwords, then other simple passwords. How much of a problem ...


3

The UUID of your cellphone isn't a meaningful second factor as it can be spoofed. On the long passwords, it is reasonably secure to use long, sentence based passwords, but the amount of security provided drops DRASTICALLY if it has anything to do with what you are connecting to. It may still seem hard to guess, but establishing a relationship rather than ...


3

My answer is simply yes. You can't assume sites are using salted hashing methods. For example, MD5 is still being used in the wild and people think its perfectly acceptable. But with a strongly salted hashing mechanism, there's just no way someone can gain access to the actual password, even if it be a low char pass. Especially speaking if your server is ...


1

In order to support "partial passwords", the bank must necessarily store either the plaintext password, or at least some values that would allow fast reconstruction of the complete password. It is easily seen in the following way: when the bank asks for, say, the 3rd, 4th and 8th letters of the password, then there are less than one million possibilities ...


10

The only sane assumptions for any web developers using local password authentication are: that their users are going to be using the same password for everything; that the site has already been compromised, even if they haven't finished writing it yet; and there will be some really expensive legal liability attached to the consequences of that compromise. ...


-6

You can't secure your password by using large scale of combination.For that you have to crypt your password.Some common crypt algos are md5,SHA-1,SHA-256 stc.But still it's not 100% secure.Attacker can decrypt your password using tools like hash cat with high GPU as mentioned above. So in a nut shell no algo is 100% secure.But you can generate a strong ...


1

They are probably storing the password encrypted (i.e. not hashed); encryption is reversible so there is no reason why they cannot use code which takes the user input characters, decrypts the stored password and checks the input matches the characters in the password. If done correctly the program used to do this would only temporarily store the plaintext ...


1

Lets not forget that someone doesn't need to brute force one target. They can try the same password with many targets making the users with the most common passwords vulnerable.


29

Picking good passwords is hard. Humans and our penchant for patterns simply aren't very good at it. Multiply that by the dozens of accounts we accumulate over time, and this is the root of the problem. So yes, eliminating bad passwords and password reuse can solve the problem of creating soft targets, but it doesn't solve the root problem of ...


29

The following doesn't really do this justice, but in summary... In an ideal world no, complicated passwords should not be required for online resources. But, in that ideal world we are dependent on the administrators of the system to harden systems to prevent unauthorised access to the 'password file', the following will minimise the risk: Securely ...


32

The long password recommendation is to protect passwords from being cracked if someone has access to the hash of that password. Tools like hashcat can easily (using gpu) test 93800M c/s md5 hashes As a user usually you don't know how does the site stores your password so it is better to use a long password to mitigate those attacks.


-1

Quoting wikipedia: It is good practice to not store passwords in cleartext. Instead when checking a whole password it is common to store the result of passing the password to a cryptographic hash function. As the user doesn't supply the whole password it cannot be verified against a stored digest of the whole password. Some have suggested storing ...


-2

What are salts used for? Salts try to mitigate the impact (the damage to users) in the wake of a successful server breach that results in all the hash digests in your database being revealed to the public and/or to hackers. Salts are used to protect those revealed hash digests from being brute-forced. So even if a hacker has all your digests, without ...


1

This is similar in functionality to using an algorithm to generate password information. Since you provided an example site: http://hash.tknetwork.de/, we can describe how you might generate a new password when you are required to change it. You can add an integer, date, or other value to the 'parameter' to iterate it You can have multiple master keys ...


1

Just to be clear, there is something else called password hashing that is completely different to what you describe, so that is a terminology collision, which is unfortunate. To handle "exceptions", you must have some storage. One method could be to store (e.g. in a local file) a map from server name to some string, e.g. an integer. The scheme would be: ...


1

Short answer: Nothing can stop the users from changing the passwords in some predictable sequence. Detailed answer: You can try various ways of detecting sequential password changes, but users will always find a simple sequence pattern that you haven't foreseen. If not number suffix - then number prefix, if not numbers - then letters. If not suffixes and ...


1

If you picked one of the three weak passwords "love", "dog" and "cow", and a password database was lost: Without salts, I can try these three passwords and find immediately everybody in the whole database using these three weak password. With salting, I have to try love+your salt, dog+your salt, cow+your salt to crack your password if it was ridiculously ...


1

A fairly simple method would be to check if the last value is a number, subtract one, use the old function to check wether it matches the old pass: // We start with 'example1', md5 -> c1285a470f0fc8f14f54851c5d8eb32f $pass = 'example2'; $lastChar = substr($pass,-1); if( ctype_digit( $lastChar ) ){ // the last character is digit, substract one: ...


34

You have to consider two attack vectors: Online attack Offline attack Limiting login guessing helps against Online attacks. Let's say it's three times, this means that an attacker can test ALL accounts for the three most common passwords that fit your password policy (how about "password", "12345678" and "12345"?). Salting helps against Offline attacks ...


1

In theory: If the attacker has not built a rainbow table, if a password of some strength can be hacked in 1 unit of time, then N passwords of that strength can be hacked in O(1) time without salt and O(N) time with salt. That's what salt does. No advantage on a fixed password; shows advantage over multiple passwords. If the attacker has a rainbow table, ...


7

There are a few different ways to check whether users' old and new passwords are similar, and each has its own strengths and weaknesses. String Permutation Comparison The first approach relies on creating a list of permutations that are not allowed. This might be a list of regular expressions or some similarly defined string changes that you evaluate ...


0

Is the benefit to changing passwords invalidated because users have the opportunity to change them to almost-but-not-quite the same password? Yes, I would say it is. If you do want to have sequential password updates, I would try to prevent users from choosing similar passwords. Is there something I can do to improve that flaw (if it's a flaw)? ...


-2

Some tools (hashcat) can perform password permutation attack based on a dictionary or initial password, it opposes a possible password hash against the current password hash (that was captured somehow) : You cannot use this tool to prevent your user from following this pattern. In the same fashion, you cannot use hashes to recognizes password patterns, this ...


1

Generally, the most important thing is password length. But it is true that an easy password could be broken down easier than a random one. For example, when you are trying to guess a hash using rainbow tables. If it is a normally used word like "cat" it is more likely that you can have it in this table than "07OFmy3HOY3l9e1gCNww7nNpd5lQ8I9an" ;D


7

Salting/hashing is great if your database gets stolen, but it has nothing to do with dictionary attacks that might take place through the normal login procedure. As you mentioned limiting the number login attempts and using CAPTCHA can make dictionary attacks that take place through the normal login procedure ineffective, but salting (or not) won't have ...


80

Salted hashes are designed to protect against attackers being able to attack multiple hashes simultaneously or build rainbow tables of pre-calculated hash values. That is all. They do nothing to improve the underlying strength of the password itself, weak or strong. This also means that they're not designed to defend against online attacks, so they ...


4

No, one point of salted hashing is to get good randomness in the hash regardless of the starting material. However, this does not free us to use bad passwords. Good hashing only protects against one attack vector: that where the intruder steals the file with the hashes. So many other attack vectors on passwords exist... shoulder surfing, brute forcing, ...


18

You cannot reasonably prevent "sequence passwords" unless you have a human administrator inspect them (which would have its own set of security issues, not even considering the expensiveness of human labour). You can try to automatically detect such patterns, but you cannot hope to find them all; besides, if you only keep hashes of the previous passwords, ...


1

If you store previous password hashes you could potentially check to see if the current password is a variation like you suggested. Say your users previous password was: password = 5f4dcc3b5aa765d61d8327deb882cf99 If you store previous version of password hashes, you can compare variations of the new password to determine if it is different enough. So ...


1

There are a number of different possibilities that you can implement to try and curtail password permutations. One of the best ones that I could find was actually on stackoverflow: http://stackoverflow.com/questions/21031661/how-do-you-test-if-two-hashes-passwords-are-similar The only problem is, you have to store a ton of password hashes. You can also try ...



Top 50 recent answers are included