New answers tagged

0

With all new browser recommendations and drafts it is really hard to tell. But in it's current state it is unlikely to be widely adopted anytime soon. For starters this is a draft. Not a standard. Nothing is finalized and subject to be changed or dropped altogether. This is the biggest reason vendors will not be rushing to implement it. The next step is to ...


-1

Lists like that exists and increase - this is a fact! Its better if used for your good instead of your bad. Simple like that.


0

Could a secure system be built that checked password updates against other people's passwords and rejected them if a password was too common? There are reasons not to do so, but if I were tasked with preventing passwords from being overused, I'd receive the password, Hash it, Store the hash in a table with no connection to any user nor even the text ...


3

Thanks to comments from @Anders (thx!), I'm unsure if the password generator is a shared service or a personal authentication token like digipass or SecureID. Password generator is a shared service In this situation, Alice can only get the signed response H(R,K) by proving to the password generator that she is Alice by presenting her PIN. If Alice knew K, ...


0

I think the best thing to do is just checking for password weakness on server side, this can be an expensive operation (in example lookup from dictionaries). Also passwords commonly used or checked for attacks are a good bet. It is possible MS first try to hash the password and compare it with a list of unsecure passwords (that are actually not used by any ...


65

We, at Microsoft, are banning the passwords most commonly used in the attacks and nearby variants. We aren't basing this on our user populations, who (because of the system) don't share these passwords unless the attacks change. The attack lists generally derive from studying breaches. Attackers are smart enough to look at lists to figure out high ...


23

A system that checks existing account passwords before deciding to block a new user's password as "too common" would, in fact, be self-defeating. You would not only be letting a user or attacker know that in fact the password is valid for some accounts, but that's it's valid for a lot of accounts. Specifically, the commonality threshold value - 1 of them. ...


0

Humans always want to transfer their responsibilities from their shoulders(Not everyone). Security is a great responsibility and most businesses want to focus on the core business and give their customers best of their product rather than worrying about the security. Single point of failure is definitely something to worry from a security perspective but ...


1

If you have (or get) a Mac, and enable FileVault full disk encryption, you can then use Find My Mac to locate your laptop while it remains encrypted, and the confidentiality of data remains. This relies on the fact that "guest mode" is active, allowing a guest user to physically login and connect your laptop to wifi, allowing it to phone home where you can ...


2

Yes, there are several requirements for an iterative hash function: It should not be possible to do any precomputation, such as using rainbow tables. The implementation should avoid running into cycles or fixed points in the hash function. The implementation should be as fast as possible, because that is what the attacker would use. Especially on the ...


3

Special characters don't add as much to security as you might think. They increase the number of possible characters, but the most powerful multiplier comes from password length. Let's say you have a very limited character set consisting of [A-Z][a-z][0-9], giving you 62 possible characters. Therefore a 10 character password has 62^10 possible passwords, ...


1

It depends on where and how you store them. The character set is what comes into play here. As long as all parts in the chain that use the password are setup to use a character set that allows these characters than yes, it's perfectly fine. A warning I say all parts because if one part of the chain doesn't support them, it can cause all sorts of problems. ...


1

If the login service is programmed properly there shouldn't be a problem with you using any of those characters. In fact, it is suggested you use a special character! When I say "programmed properly" its because sometimes a programmer will not set up his database to support "UTF-8" and then a character such as "ç" might not work...


1

Trusted party is exactly that. Someone who is trusted when he identifies you. The most basic vouching happens when you go in front of the HelpDesk and tell them that you forgot your password and are now locked out of your account. Then the IT staff vouches that it's you and resets your password. Now suppose that no domain admin was available when you went ...


0

I would say because it allows a massive increase in potential damage if one account gets hacked. Say I want to get into account A. If account A set up account B, C, and D into vouching for them, I have 3 more potential targets I could try to weasel access from. One of them is bound to have a weak password or is susceptible to social engineering. Now that I ...


4

A quick search turned up the link below. They created a new technology called CredentialGuard, which isolates secrets in virtualized secure environments rather than storing everything in LSA like they used to. Mimikatz can no longer just dump lsass.exe process memory and parse the contents. They're still in some memory, strictly speaking, but not memory ...


3

Your action is justified from me. I have never been asked from any major and respectful company such information, neither for a service, nor even for account recovery. Send a message to the official support team and see if these info are actually needed if this thing causes you lots of inconvenience. But be aware of this - you might be scammed.


1

usually a user table provides the relational association to content in the actual database. eg user:jon_smith posted this blog post The user table is also the logical place to store login credentials. The problem/question is not 'why is a database storing login credentials', but rather 'why arent people storing hashed values of passwords and comparing the ...


0

So why do we even use full-power database software and SQL queries to handle the pretty limited needs of username & password authentication at all?. Why aren't there limited-purpose database applications specifically aimed at just doing what a password database needs to do, vs. using general-purpose applications that leave lots of room for SQL ...


2

I think that onetimesecret.com it's a very useful service, and it fits your needs. Of course, you should share the onetimesecret password by a different channel in order to increase the security and avoid the case of compromising the sensitive information if someone has access to the email account. I have dealt with these situations before and, depending on ...


1

Where I work we have a solution that will automatically detect sensitive information and replace the content with a link to a secured server. The company that sells this makes a business out of it so this isn't a crazy idea. As long as you make the links impossible to guess (long crypto-secure random strings.) The solution we use actually requires the ...


1

There already is a solution for encrypting email: It's called PGP and there are plugins available for most email programs on most operating systems. Its main problem in the real world is that you need the public key of anyone you are going to send an email to, but when you are using it internally you can fix that by setting up a keyserver on your company ...


1

Another angle to symcbean's answer. The whole situation seems rather simplified. Who should take care of what can be queried and what can't? The underliyng DB (using special tables for user storage), the backend of the web application server or even a WAF? What about queries including LIKE statements (i.e. PasswordHash like 'a%', you can see where this is ...


0

Generally, in terms of security, reusing passwords is not a good idea. Mind that the revocation is not the only problem if you get compromised. An attacker with access to your previously encrypted messages, by having the key and password, is gonna be able to decrypt them. So, having different passwords makes the attacker's job harder. Also, making this ...


2

For encrypting data, it's generally recommended to store a random key and encrypt this with the appropriately salted password. This means that if/when the user changes their password, you only need to decrypt and re-encrypt their key, and not all their data.


0

Well the most popular reason for this happening are the following: Someone has hacked into your account and changed your password yet Steam keeps you logged in - In this case you should change your password to your Steam and Email account. This is a bug and you should contact Steam - This page should help you troubleshoot your problem and contact steam if ...


4

Do not use SHA256 to hash passwords. SHA256 is a message digest algorithm. It is designed to be very fast. Use an algorithm which is intentionally designed to be slow and hard to implement in specialized hardware. Why? Because fast algorithms allow an attacker to brute-force a large number of passwords until they found one which works. "They'll still have to ...


5

There's a big gap between "does not require" and "implemented by the lowest bidder". why do we even use full-power database software and SQL queries Because if you're already running a SQL database for your transactional data, implementing a second technology stack with appropriately trained development and support staff for a very specific function is ...


3

The security lies in that you have a unique "access token" per client. So you can revoke and control as you will. Look at for example, Googles "App Passwords" which are the same thing. These tokens, of course make the 2FA no longer 2FA, but thats required for software and programs that do not support 2FA at all. The idea is that if a token becomes ...


2

JDBC is a Java API. It uses JDBC database drivers to actually communicate with database servers. These drivers may or may not support TLS. The PostgreSQL JDBC driver supports TLS: https://jdbc.postgresql.org/documentation/94/ssl.html So, it would connect to the database server using TLS, then send the username and password to authenticate. You would not ...


0

Generally speaking, storing that information in the DB, encrypted is the better choice. Is there any reason you are not doing this? I would be less worried about an attacker trying to attack the Laptop via a leaked Local IP since most laptops don't allow incoming connections, I would be more concerned about a person clicking a link which compromises the ...


0

Yes, hacked data dumps of credentials are often used to breach hundreds or even thousands of accounts at different sites. In fact, SWIM tells me it's actually quite trivial to do.


0

Fortunately or unfortunately depending on what side you are on most people use the same password for every site. Therefore, it makes it really easy to steal passwords from insecure websites, especially android apps or even wifi. Then you use that same password to escalate to other sites such as bank accounts, etc. Then if you get into someone's email it ...


1

Yes, they are. I suggest you skim the Verizon Data Breach Incident Report. Last year, 63% of confirmed data breaches involved weak, default, or stolen passwords. ... The capture and/or reuse of credentials is used in numerous incident classification patterns. It is used in highly targeted attacks as well as in opportunistic malware ...


2

Yes, stolen passwords are used in real life attacks. I didn't actually know myself until I searched, and it's buried all the way on the third page of my fourth or fifth Google search; i.e. the information practically doesn't exist. ;-) Anyway, apparently back in 2012 there was a period of several months where Best Buy accounts were compromised by stolen ...


0

You might be somewhat safe if your suffix looks like a year of birth. If I use myname1977 then there is less, but probably not zero, chance that someone knowing that password will guess that I changed it to myname1978. But why take the risk? (do as I say, not as I do; I increment, but only at work, because that's the only place that asks me to change my ...


0

Probably not the most secure answer, but I recently heard advice about what to use for passwords that change regularly: What is your goal or something else you are looking forward to doing in the next X months? Use that to make a password. So, if you are going on a trip to Disney World before your password is going to expire you could do something like ...


1

I think it would be possible to somewhat significantly reduce the search set, but it largely depends on the resolution of the picture and the worn state of the keyboard. With a visibly worn or dirty keyboard (dirt on the edge of keys could serve the same purpose), you would first establish the possible alphabet, with each key weighted at 1.0. Then establish ...


7

Only if the sole purpose of the keyboard is to type one password. Otherwise, you'll find that more frequently used keys such as vowels, WASD, and modifiers will also have oil stains and signs of wear. It becomes especially more difficult if the password is a passphrase containing natural language.


1

What information can I give my friend such that, if A and C want to log into Y with their X credentials, they can, but also ensuring that the information of B is protected? The short answer is "nothing." Since you don't know who out of the set of all users wants to be associated with the new site, you would have to include the entire set of users. ...


5

What you are asking to do violates some foundational concepts of security, so I am advising against a technical solution. Credentials are meant to validate a user against that trusted asset. Passing those passwords to a 3rd party breaks that trust (even if you trust the 3rd party, your users do not have that chance). If I was one of your users, I would be ...


1

I assume that the passwords are not stored anywhere and that verification is done using hashes. You have two choices, basically: Give Y a dump of username and passwords and let Y care about how to integrate those Use SSO (e.g. with OAuth): X becomes the trusted party and Y the relying client. This option works for all users registered at X, no matter when ...


-1

Only the most simple bruteforce would work that way. A much better use of your time would be to add an extra character. If you go here http://calc.opensecurityresearch.com/ there is a calculator that demonstrates how much password length matters. For example, using only upper/lower case alpha, md5, a 10 character password takes 531 years to brute force. A ...


0

When I'm cracking passwords I will get your new password within the same second if all you do is increment. This is because I'm trying appended and prepended passwords before anything else and only after qwerty related schemes and the basic list of discovered passwords since it's been my experience that's what we humans are apt to do.


3

The biggest difference is in scale. A keypad on a lock is generally only used to type the password, so the password keys are the only ones being used and worn. "Any given keyboard" is generally used for much more than only typing passwords. There are many other attacks used on keypads: video cameras watch you enter your pin, heat sensing (flir), or even ...


0

Keyboards wise, I'd consider this a minor concern unless I was using the same password for everything. If you're using a different password for everything and changing them reasonably regularly, you're probably fine. Add this to the fact that if you're using the keypad for other things you're going to get a much different wear pattern than just P A S W O R D ...


2

You need to clarify the term "keyboard". If you take a pic of my keyboard I am writing this text. You will surely notice some patterns and missing letters from my typing. But be aware that most of the time such keyboards are not used to enter passwords at all. Typically you rather get a heat map of the frequently used chars for a certain natural language. ...


71

Yes, you should hash your passwords. Storing passwords in plaintext is not acceptable. No, it does not affect the amount of traffic your site require. The hashing should be done server side, so it does not affect what is transmitten from the client. Hashing the passwords protect them from theft once they are stored in your database. To protect them from ...


49

In some cases yes, you can guess the most frequently used keys by the wear marks. That's how I know that apparently I use the L, M, N, A and E keys a lot - the keys are now just black, the letter is faded. But most people don't use the keyboard for just their passwords, and the wear pattern is also influenced by the stroke direction, angle and pressure - ...


18

There are two different scenarios. This would be a valid question if the keyboard is used only for password typing. A numeric keypad on a door, that's something you shouldn’t post on social media. But you can argue this by saying that there are special characters on your keyboard which may be included in your credentials, because normally we don’t use those ...



Top 50 recent answers are included