New answers tagged

0

It would have a slight advantage that bots or attackers that haven't done their reconnaissance properly may be wasting time on password guesses with passwords that the system can't possibly accommodate. If an attacker can register for their own account, they should have checked the maximum password length and other password rules by trying to reset their own....


0

My question is, is there any actual security advantage to forcing a character-limit on password-reset, and then allowing unlimited characters on login? I can't see any security benefits to that. Allowing unlimited length at login is probably not a concsious design decicion, but rather the result of the developers not bothering to set the maxlength property ...


0

The only security disadvantage of password-length restrictions (I.e. "Not too large") is if the software is vulnerable to a buffer-overrun. Those are not difficult to defend against for password fields, so this is just laziness on their part. Other than that, password length restrictions can only artificially reduce the possible entropy in a password.


3

Password strength meters are notoriously weak: New research from Concordia exposes the weakness of password strength meters and shows consumers should remain skeptical when the bar turns green. In general, adding a character to a password will not make it weaker. There are only specific situations where this isn't true. For example, MyPasswor is ...


5

John is not typically run on victim's computers. It has two uses. First, an attacker runs john on their computer to try and crack a victim's password. Second, a sysadmin can run john locally to look for weak passwords. So I wouldn't assume that you've been hacked just because john was installed. From the message in your post, it looks like you installed ...


-1

Your sha1 password simply becomes the plain password for an eyedropper. What I do is the following: On the database, each password is encrypted with bcrypt and a salt. The salt is "public". When the user log in, the following happens: -> client send username -> server reply with "salt" -> client generate a random nonce -> client send "bcrypt(nonce+bcrypt(...


1

As tim wrote, it could help mitigating the effects of password reuse for users in a few cases, but if what you're thinking of is hashing it client side instead of on the server side, this would be a major design flaw. https://en.wikipedia.org/wiki/Pass_the_hash This problem plagues the NTLM authentication, where it's actually even worse than in the common ...


7

I'm assuming that you are talking about additional hashing. So it would look like this: Client --sha1(password)--> Server --bcrypt(sha1(password)--> Database I think you are aware of this, but just to make it explicit: the transfer needs to happen via SSL to defend against eavesdroppers, hashing client-side would be no help against them at all. ...


0

It's 2016, so it's well worth revisiting this 5 year-old question. There was a Password Hashing Competition conducted from 2013 to 2016, which accepted 24 submissions and selected Argon2 as its recommended password hashing algorithm. Everything that Thomas said about new vs. good still applies. As recently as February 2016 (after the end of the contest) ...


0

The salt has to be stored someplace that's easily accessible given a user ID. That means a database table. The hacker who can get the hashed passwords can get the salts in the same way, often using SQL injection. As others have already written, the salt stops precomputation attacks. There is an approach called a keyed hash in which the hash is generated ...


0

Others have clarified the purpose of Salt, which is to require a separate brute-force process per-user to crack, which would take much longer than a single brute-force process finding matches for every user at once. Salt is not needed to be secret, just unique. A good way to improve on this is to include Pepper, which is secret. Pepper is just some random ...


1

The purpose of salting is, that one cannot build a rainbow table to get several passwords at once. Without salting: An attacker could search the internet for precalculated rainbow-tables and find the passwords with no effort. With a constant salt: The attacker has to build one rainbow-table for this specific salt, and can then get all the passwords with ...


0

You answered your question, just did not saw it. why all people say on SO or Internet anyway that putting the salt in the database is good practice or safe The answer is: if I hack to a database (...) I will take the salt of the first record for example and make a dictionary of all hashes of all english words ( rainbow table ) and then I ...


2

To answer your questions: Should all web applications implement such a security feature? This is just another good security feature to help the user so if the application can afford (resources not financially) to have this implanted in their system there is no reason not to. Is it desirable that companies store our historical passwords? Since ...


1

If you use 4 or 8 bytes of integers to store your passwords, you are making the brute-forcers' jobs a lot easier. Because, if i understand your situation correctly, an attacker would just need to come up with an string so that its converted value(converted to check with the values in DB) matchs the stored password value. Considering the computing power in ...


3

This is security through obscurity, and in violation of kerchoffs's principle. if they don't know the algorithm they wouldn't be able to crack it? Maybe. And maybe analyzing the entries leads to the revelation of the algorithm. And once an attacker does get the algorithm - via analysis, by getting access to your server, because you posted it here - ...


0

Actually most implementations of algorithms like BCrypt will generate a salt on their own, from the random source of the operating system. This is the best one can do and there is no need to derrive a salt from other parameters. A salt should be globally unique for each password, so an attacker cannot find any precalculated rainbow-tables, and would have to ...


0

Use a key derivation function (e.g. PBKDF2) to create an encryption key for a cipher (e.g. AES) used to encrypt your password file. It provides protection against brute force attacks (admittedly PBKDF2 isn't the best KDF, but it's widely available). BUT beware of things like the data finding it's way into the page file or in a temp file somewhere.


0

The only other solution than asking for a new password is to save the new hash on next login, setting a flag to know it's upgraded (if needed). This approach is as secure as your current login, and based on your question, will improve it. Changing the current hash is pointless as it will not add entropy.


1

Relying all your security in a single file is dangerous. The file can be easily decrypted even if you use strong passwords. The reason is because the amount of attacks that can be done per second is incredibly high (more if you consider that a copy of the file can be attacked by multiple computers at the same time). As Alexander pointed out, there is ...


1

The email is referring to a breach of the LinkedIn password database that happened back in 2012. This was one of several HUGE breaches that was discovered around the end of May 2016, all of which actually happened earlier. Although we knew about the LinkedIn breach a few years ago, we thought it was only a case of "some passwords were stolen". 6 million ...


0

MD5 is broken with regards to creating collisions. That means that it is possible to construct a message M1 in such a way that you can also generate a message M2 so that H(M1) = H(M2). For this the messages M1 and M2 must be pre-constructed in a certain way. So in case of CHAP M1 would be the nonce | password combination. The vulnerabilities of interest to ...


0

If you use the same password for other websites it definitely leaves you vulnerable. I'm not sure if it's a phishing attempt, however if you've started to form a pattern for repetitive password use it may be the smartest move to change to something new.


2

There are methods of stealing browser-saved passwords so you need to assume that your browser is always vulnerable. At a very minimum, you should set a browser master password and enable encryption to stored passwords. You can also look into using something like KeePass which allows you to store encrypted passwords where you choose (i.e. hard drives, ...


5

You should assume so no matter what* When your system gets compromised you must assume that it has compromised any accounts stored on the system. You should go about changing the passwords for any accounts used on that computer in any place. You have no control over the virus, and you have no control how programs store your data so you don't know if your ...


3

In general, use the maximum cost factor that is bearable from a performance perspective. I would create a benchmark application which is as close as possible to what your application does, and find out the cost factor on your production hardware that gives you the maximum tolerable delay. In most systems, I strive for a 10 to 20 ms delay. Assume your ...


2

Your case is documented in the Trillian Security Practices. The mobile device version of the software will store your Google password encrypted on the company servers of the Trillian developers. This allows them to keep your GoogleTalk session alive, even if your mobile device has bad connectivity. It also allows you to use the web version of the Trillian ...


1

While @Anders answer is accurate, I want to extend his case for dropping "low entropy" passwords and I couldn't fit it in a comment. Firstly, I wanted to introduce a parallel. Many ciphers (e.g. DES) have weak keys, which make encryption behave suboptimally. This implies that there is no "flat keyspace" (one where all keys have the same "strength"). If ...


1

As a start, try this paper, which assesses 34 password database breaches. It states the following on page 2: While absolutely no information on how the passwords were stored could be found in 26.5% of the cases, we found 11.8% reported passwords were “Hashed and Salted”, 5.9% used salted MD5, 14.7% used unsalted MD5, 11.8% used salted SHA1, while ...


22

As web developer, I agree with Andrew it all points that it was a developer's mistake. They probably password protected some of the resources required for some of the ads (for example, css, js, a font, an image, a json, etc). I tried with my gmail account and is also happening. The protected link is: https://googleads.g.doubleclick.net/pagead/drt/si?ogt=1&...


2

First of all if the domain name (the fully qualified domain name left of the rightmost period) isn't Google, I wouldn't log in. You should always look for the right most period. Once you hit a slash (/ or \), you have superceeded the domain name. not a dash or hyphen, that could be a part of exampledomain.com, etc. basically make sure it is Google, you can ...


6

In general This depends on what information you are asuming that the attacker has. First, let's asume that the attacker is blind, and perhaps trying to crack a large dump of breached accounts, without knowing that you used that specific algorithm. Then you would be better protected if you discarded 123456 if it comes up, or more realistically, passwords ...


0

SHA256crypt and SHA512crypt was described by Ulrich Drepper here. He provides an algorithm and implementation, but unfortunately not a security analysis, any proof that this algorithm is secure, or any insight in his design decisions. This makes it hard to analyze the security of the algorithm. The algorithm is pretty much like PBKDF2, in that it performs ...


8

It might be a (extremely poor) phishing attempt, or it might be just a misconfigured ad server (asking for the login and password due to .htaccess). Report it to Google (as they own both GMail and doubleclick). Don't panic. Changing password is probably not necessary, but I still recommend doing it it (you should change your paswords at least semi-...


16

This is an HTTP(S) Auth window. It looks like one a Google Ad is using it to ask for your Gmail credentials. However, there's no legitimate reason it would do so, especially over HTTP (unencrypted). You should report it to Google immediately.


67

This seems unlikely but not unthinkable. From the information in your question and the supplied screenshot, it seems that the Google ad domain was or currently is compromised. What todo now? Firstly, make sure that you have antivirus and anti-spyware software installed and that this software (including your operating system) is up-to-date. It is a good ...


0

Unfortunately, even today there are some major companies where a human customer service agent asking you (whether via chat, phone, or other means) to tell them your PIN, password, or passcode is a regular practice. To take one very prominent category of these situations here in the U.S., when you call customer service for one of the big four national mobile ...


2

It depends what you mean by "secure" :) CHAP: Client authentication request send its user name to the server Server responds with a nonce Client calculates hash(nonce|password) and send to the server Server verifies the password Cons: All data is transmitted in clear text i.e. it possible for an attacker to eavesdrop and brute-force the hash offline ...


2

The entropy of a password is a quantitative statement about the probability distribution of all the possible passwords. To simplify this, think of a probability distribution as a rule that, given a password, outputs the probability that that password is the one that was chosen. So you really can't put a number to the entropy of a password unless you start ...


2

I totally agree with the answer by @ChrisTsiakoulas that your action is justified. However, sadly, this practice is not quite as uncommon as we would all like. I intend this answer to add a bit more colour to the real-world situation with such practices. I have come across the exact scenario you describe, although it was with a "proper" password (referred ...


0

Another problem not mentioned yet: you mentioned the JavaScript is served over plain HTTP. This means that a "man in the middle" (MITM) attack can modify the JavaScript enroute, removing the encryption, or even doing more nefarious things. You CAN do encryption client-side (there are some cases this makes sense) but it CANNOT replace HTTPS, only supplement ...


4

The proper way to calculate password entropy is to look at the password generation method, evaluate how much entropy is involved in the password generation method, and then evaluate how much of that input entropy is preserved by the encoding method. As an example, throwing a fair 6-sided dice once generates approximately 2.5-bits of entropy (note that it's ...


2

KeePass describes some of what they consider here, and it is described with some more detail on page 18 of this excellent paper: Carnavalet, Xavier De Carné De, and Mohammad Mannan. "A large-scale evaluation of high-impact password strength meters." ACM Transactions on Information and System Security (TISSEC) 18.1 (2015): 1. It would be too long to ...


4

Data entropy depends on the observer - there is no absolute measurement of entropy. It's even questionable as to whether or not anything in the universe it at all random, and "randomness" (or, more precisely, related to entropy, unpredictability) is the source or entropy. Unpredictability being the operative term: hard for somebody to predict. If you use ...


0

Well left to me, if you have a client running a cafe like mine does and he the client doesn't want to go LAN, maybe a combination of a MAC filter and a wps would be fine. For example my client complained that some friends of his apprentice connects to his network just by getting the password on their (apprentices) system, be it wep, wpa, wpa2 , tikp, once ...


1

No. I would say, that the 2FA device in question, will protect your account more than the password. The idea behind the 2FA device, is to prevent someone remote to you, to access your account. Eg, hacking it from the other side of the globe. (NOTE: Does NOT apply to certain event based tokens with 6/8 digits - see later) However, changing password is a ...


3

Indeed, two factor authentication (2FA) will prevent anyone from accessing an account without having both authentication factors. That being said, the typical implementation of 2FA online is a password paired with a short code, either on a keyfob or sent via SMS. The standard RSA SecurID keyfobs that have been around for a couple decades now and Google's 2 ...


0

When using Hydra, you normally use -P password_list.txt to specify the input passwords. You simply need to md5sum this list. Consider this script hasher.sh: #!/bin/bash filename="$1" while read -r line do echo $line | md5sum done < "$filename" Now you can hash your original password list: ./hasher.sh password_list.txt | cut -d" " -f1 > ...


2

What are the risks of storing (in hashes I guess) all the old passwords? The risks are very low, since the old passwords will not allow access to the account. Why would a company chose to not delete old passwords? Companies store old password hashes so they can check to make sure that you do not reuse x number of old passwords. Why not let ...


1

What are the risks of storing (in hashes I guess) all the old passwords? see here But just because you cannot use your old password doesn't mean that they necessarily store all the old passwords. They could just hash the password you provided and compare it to the stored hash. Why would a company chose to not delete old passwords? To prevent you ...



Top 50 recent answers are included