New answers tagged

-1

Master passwords and encrypting them on your computer further than what the OS already offer shows this is nothing more than security theater. Although it is convenient, it still leads to risky practices, and even worse makes it easier to forget your passwords. The Actual Impact on Security A great quote about why Chrome doesn't use a master password ...


1

Yes it can work, if handled properly The benefits are clear: it is harder for someone else to log in with your password. Guessing becomes harder, and even if someone has (part of) your password, he's not done yet. So, I will adress the concerns: Yes you can still log in with a broken finger Sure, the password can get 'lost' when you break your finger, ...


1

It is a very cool idea, but if it wasn't implemented correctly as everyone else has said it wouldn't work because people change and the fault tolerance would have to be implemented correctly. My idea for a good way for this to be implemented would be to see if the user inputs their password in the certain time pattern and if it isn't and the password is ...


0

I think that this would have the most potential for situations where a password is used often and the input doesn't allow a large variety of characters. An obvious example would be something like a door entry code. This also has the advantage that even if somebody is able to see the code itself over your shoulder they still have to get the rhythm right. This ...


0

In the worst case (from the perspective of the security defense, not the attacker), salts do not add any time. All hashing functions, in principle, have a salt: some initial state which is perturbed by passing the string through the algorithm. It's just a question of whether the salt is modifiable (is a parameter of the hash) or fixed. A hashing function ...


1

In your specific use case, this assertion is faulty: ... suggested that a small digest is susceptible to rainbow tables and other attacks ... A rainbow table is only a lookup table of pre-computed digest values. Think of your use of a hash like the index at the end of a book, telling you what page number to read to find the real context containing ...


1

Let me answer this based on how PGP/GPG works. So you have a file for say Client X, and you are using FTP as a delivery mechanism. You want to ensure that your data is protected (encrypted) and only Client X can read it. To do so, you would be using your PGP key for signing, and they will use their key for decrypting. You (PGP key which can be looked up on ...


1

It is possible, if your server accepts files uploaded by an anonymous user and if you don't provide a hash (e.g. SHA-256, SHA-512,...) in order to check that cred.gpg actually contains passwords.pdf and not evilfile.pdf.


2

In practice it literally doesn't matter. If your key size is 512-bit (I'm not sure what cipher you're using, as none that I'm aware of use 512-bit keys, but whatever) then you've got two scenarios: In a small digest you've got so many collisions that discovering the original key by looking for matching values will give you a silly number of results. Not ...


1

I once implemented something like this. The longest known words would be removed from the password before checking its length. So if you enter "test438" as a password, "test" is removed and "438" is obviously too short to be a password. This still allows for passwords that combine multiple known words. Some people that had passwords like "Test1234" ...


1

It's not used widely because if you block 123456, users will use 1234567, you block qwerty they'll use qwertyu. Honestly, "The blacklist approach will be bypassed". And this makes the outcome minimal, to the extent that its not worth implementing. The approach could be beneficial but when coupled with other types of policies like min-length, uppercase, ...


1

Disable wireless administration: Change the setting that allows administration of the router through a wireless connection to off . This means that you need to connect with a LAN cable for administration. This disables any wireless hacking into the router.


2

This reminds me of how Dan Kaminsky got hacked. He used to use passwords like: fu*k.hackers fu*k.mysql fu*k.vps So bad guys has revealed his pattern and the rest of the "job" was easy. The lesson of the story is; stay away from this.


3

Your system is also known as the monthly updates of passwords where the last two positions of a password are change with the number of the month. It didn't work 20 years ago and it will not work in the future. Computers are much better at generating random strings and/or telling remote systems that you are you. So getting a good password managers and ...


4

Password patterns are subject to the same fault: they are only secure if the pattern is unknown. Worse still, in your pattern, it is subject to the site it is found on, making the pattern more obvious. What happens if someone gets ahold of one of your passwords in clear-text? They can derive all the rest of your unique passwords. Patterns can have their ...


1

Theoretically, yes, since your password has been sent to Google and is most likely stored somewhere along with billions of other short strings. In practice though, the probability of that password getting out of that database and somehow making its way to an attacker that tries to use it to access your account is several orders of magnitude lower than many ...


0

Rather than have it brutally block/allow the user you could have it " learn " the user's method over a period of 10-20 logins and take the median with a slight margin of timing. Regular login: - Password + two factor login by app / sms / email link After a while you'll know his pattern, and can give the user the option to enable the added security, and ...


5

It's doubtful, but consider the following The connection to Google Search is encrypted. As far as we know, Google Search History has not been compromised. In the event you have Google Search and Web History Enabled, your search history could theoretically be accessed by someone who managed to break into your account. You stated that you didn't press enter; ...


-4

It can't be possible (as far as I know PHP and MySQL). That's because PHP (a language in web development) tells MySQL (database server) to store your input after it's SUBMITTED. And the auto-completion, I don't know much on it or what language is used to make that kind of feature, but I think it just gets what matches more with your string (i.e your ...


1

I think you're asking the wrong question, and will suggest some edits. Your question ("Because of autocomplete, is my password at risk?") implies you have a single password, and worries about the exposure threat from typing it into a search engine. You probably don't need to worry about that, but you do need to worry that one or more of the sites at which ...


4

Even though it was probably encrypted as others have stated, there's a risk that it may be displayed again as a suggested search if you were to type the same first few characters as part of a real Google search. If it was displayed again it may be at risk from shoulder surfers. So I suggest you change your password.


5

I've done a little work in this, and some related areas, and my response to the question depends on how much time you've got: Short answer: Yes, with a but. Simply put, as you've discovered previously, there are similarities in observed keystroke (or other behavioral biometric patterns). These can, theoretically, be used for additional security, but the ...


4

Another reason for no: Assume your user mistypes their password occasionally. You may type it perfectly, but the rest of us have fat fingers sometimes. They will probably type it more slowly on the second attempt and screw up your metrics. This is particularly true if there's any detectable timeout/delay (rate-limiting or just a slow login server) as they ...


38

I recommend that you change your password. The fact is, that your password has been sent to their servers, even if you didn't press enter. You can test that on your own, open your browser, Ctrl + Shift + I, select network, start typing and monitor traffic. Here is an example, writing the keyword "test", and not pressing enter. Pay attention to the letter ...


1

Let's call this timed password entry. Essentially, what you are doing is this: Trying to increase the password entropy. This has some cons, such as the fact that people change, and it might bite you back after some years. The question is: is this method of increasing password entropy worth it? To answer this correctly, you need to first measure total ...


91

I highly doubt it. You didn't press enter but Google will sometimes send the information to quickly present your results. This is forced over HTTPS. Your information was likely encrypted and not exposed. According to most sources Google processes on average 3.5 billion searches per day. There is no additional information to prove your query is a password. ...


12

Yes, it's more secure. It would make a 8 character timed password as strong as a ~9.5 characters long non-timed password. This would be a form of keystroke dynamics. It's been an area in active research for a while - although software running on an Amiga probably predates most of it! There's a python package for that, in case you want to experiment in a ...


7

Theoretically, you should change your password, as by typing it into google the password is sent to google. Google does use https however, and I personally wouldn't be too worried about google having my password as a search, but hey, it's not ideal. Realistically, I think you should be fine, but if you want complete security, it can't hurt to change your ...


25

It has been sent (encrypted) to Google. Change your password It has probably been logged somewhere, along with many search terms and other junk people have typed there. While it's unlikely it will be used for anything you care or that endangers your account, why bear the risk? Simply changing it will solve it. PS: I recommend using a browser search bar, ...


16

whether it was a viable addition to security these days The only reason I don't think it would be viable is people log in from so many different devices these days. I can promise you there is no correlation to the rhythm I type my password with on my main work desktop and the Swype keyboard on my tablet.


6

Since this basically precludes use of a password manager, which is baseline best-practices for password security, it does not improve but harms password security.


35

There's some good, some bad, and some REALLY ugly in here. The Good It increases a passwords entropy and makes it harder to brute force The Bad It is based on something that can be audibly recorded and timed and needs fault tolerances meaning something only has to be close enough to render this moot The REALLY ugly People change over time. For a multitude ...


95

The term you are looking for is "keystroke dynamics" or "keystroke biometrics" and is an interesting and growing field. The idea is that an individual types certain keys in a certain way that does not change much over time. If you can map those dynamics, then you could, potentially, do away with passwords altogether and simply get the user to type ...


5

It's a neat idea, and the net effect would be an increase in password entropy. For example, suppose your threshold is 1/4 second and the maximum pause is 1 second. At some point the pauses would be converted into bits, and this would effectively increase the password character set by 4X; e.g. an 80 character set would become a 320 character set. A 10 digit ...


83

I think it would be very, very annoying to legitimate users of your application or website. Things like a broken finger, or just holding a sandwich in one hand, would make your login unusable. Additionally, you should encourage the use of password managers, which will either send keystrokes extremely quickly, or will not send keystrokes at all. Your scheme ...


6

Answer: No, a bruteforce attack would most likely fail. http://www.payetteforward.com/my-iphone-is-disabled-connect-to-itunes-fix/ According to this site, and anyone who has ever been a mean big brother, there are only 10 times you can attempt to unlock an iPhone before it is completely locked and needs to be restored. 1-5 failed attempts - The phone will ...


4

Generally, it is ill-advised to implementing your own session handling. If you can, you would be better off by using a well known and well tested implementation. These are the issues I see in your procedure. User requests password reset How will you handle misuse of this function - will you send one email per reset attempt, or will you implement a ...


2

Typically if encryption is used, it's proper encryption and the fault is in the implementation. Or if the implementation of the cryptosystem is perfect, there could still be a thousand other things wrong. I'm not sure you're asking the right question when asking whether AES is secure. If you want to judge whether they know what they are doing, you could ask ...


2

I see two possible problems with this: Browser/Application Autocompletion If you do it in a web browser, and the field you enter the password in can allow data to be stored by the browsers autocompletion - then people with access to the browser can find your password. Either by chance, or intentionally. If you enter passwords in a password field, it should ...


2

Your assumption is wrong. Cryptographic hashes are not generally designed to be slow. Quite the contrary, the most widely used hashes such as MD5 and the SHA series of cryptographic hash function were developed explicitly with speed in mind. They need to be, because they may be used to hash huge files or provide integrity check for internal file system data ...


0

My new found understanding: Two types of logons for this- one stores and one doesn't: Interactive logon occurs when a user enters their logon creds at boot, RDP, or other interface on the local machine. This logon type injects user’s credentials into memory as Kerberos tickets TGT, NTLM, LM, or plain text. This logon type is the primary security concern ...


-15

No, because your hashed password is just plain text anyways. The hashing takes place when you create the account, not each time you log in. If someone is using the same password as you then they will have the same hashed password as well, which is why many sites require complex passwords. Those plain text passwords will take about as long to retrieve as ...


2

If you do the hashing on the server side, the server (and an attacker with access to it) could read your cleartext password, correct. But hashing the password on the client does not really help if someone managed to get access to the server - because the attacker could easily alter the javascript source to get your password in cleartext or start ...


1

I suppose it depends on the circumstances. If you're running a Windows 95 machine on a dial-up connection to a webservice running on an overloaded Unix box from 1990, then yes I imagine it would take a second or two to return back a result. However, we are in 2016, where CPUs run in the GHz range, and internet speeds run into the MB/s. Hashing to a ...


22

You can't make that assumption. Hashing occurs extremely fast, even a password that's salted, and uses a secure "slow" algorithm (or even chained set of algorithms) is going to return very fast (for humans). A ballpark estimate for using PBKDF2 with 10,000 iterations for each logon attempt could handle 100,000 attempts in a second (when only looking at ...


4

While I'm not familiar with CRC-96(ZIP) I'm assuming it is a longer version of CRC-32, but similar in it's function and implementation, so my answer is predicated on that. CRC is essentially a one-way function. Like other hashes this is a lossy operation, resulting in an output of a pre-determined length. You could put in the word 'cat', or the entire ...


3

SANS first ran an article on the basics of what you are looking for -- a way to detect mimikatz on the network -- https://isc.sans.edu/diary/Detecting+Mimikatz+Use+On+Your+Network/19311/ However, remember that mimikatz is capable of Kerberos attacks -- https://dfir-blog.com/2015/12/13/protecting-windows-networks-kerberos-attacks/ -- as well as PtH attacks ...


1

With regards to your first question, you probably should make that an option or at least query the user on which piece(s) of information they've forgotten. If they forgot their password but remember their security question then it doesn't make sense to require a new security question answer. If the user forgot both then they'll need to reset both. You ...


2

You should send the password reset link (or code) to a predefined email address (or phone number). This is the only protection in this scenario. So called "security questions" are not "less secure" they are totally insecure and if used incorrectly they decrease security as discussed here Do security questions subvert passwords?. The only reason to use them ...


6

It is common to have default passwords on devices. After all the camera needs to have some password when it is shipped, and the manufacturer clearly thought that it would be to complicated and expensive to set a different password on every single camera and print it on a piece of paper to include in the package. The intention is that people should change ...



Top 50 recent answers are included