Tag Info

Hot answers tagged

55

Do you remember earlier this year when Apple's cloud was hacked? Well, Apple's cloud wasn't hacked. Some celebrities with really weak passwords had their passwords guessed. But the headlines will still read that Apple's cloud got hacked. And that is why you don't allow users to use really weak passwords.


41

As Mike and Gumbo have mentioned in comments, a salt isn't intended to add protection to bad passwords. It's meant to keep the attackers from breaking the whole database at once. The length of the salt isn't meant to add difficulty to breaking the stored passwords. It's meant to ensure that your salt is reasonably unique compared to others on the Internet, ...


21

Basically it's using the suid bit. If you check the passwd command in your machine: -rwsr-xr-x 1 root root 43K Feb 15 2011 passwd SUID (Set owner User ID up on execution) is a special type of file permissions given to a file. Normally in Linux/Unix when a program runs, it inherits access permissions from the logged in user. SUID is defined as ...


21

Some users will not provide any personal information and not care if their account gets hacked. Others will. It's easy to require strong passwords from everyone, and difficult to work out which users fall into which category and require strong passwords only from the latter group. So why would they bother to do it the difficult way? Edited to add: What ...


14

A too long salt will not reduce security. A too short salt will reduce security. As the salt gets longer security will improve. At some point you will cross a boundary, where you start getting diminishing returns on increasing salt length. And eventually you will cross another boundary, where a longer salt does not add any security whatsoever. However ...


13

SQL Server has the option to encrypt the connection between application and database. When you operate SQL server in an untrusted environment, it is recommended that you enable it. When you do, hashing the passwords before sending them to the database is unnecessary as long as you trust your DB administrator. Additionally, most deployments of SQL server ...


12

There is no good way. What you say, is practically the measurement of the password distance in our mind. It is clearly impossible to have a direct method to do that. Second thing, what you want to measure, depends heavily on the person, and contains often only for him known informations. For example, one of your collegues could use the name of its childs on ...


10

Just because it doesn't matter to you doesn't mean it doesn't matter to anyone. I got a kick ass job from StackExchange's employment site, based largely on my reputation on the StackExchange sites. If my account were compromised there could be very real consequences for people like me. Regardless of whether you care about your account being compromised or ...


10

Two-factor or multi factor authentication is based on three possible forms of authentication: Something you know which is considered secret (password) Something you have (token, SMS token, card,...) Something you are (biometrics) If either two of these three are combined, you can speak of two-factor authentication. Saying two things you know (such as two ...


9

There are several reasons why this would be a sub-optimal security scheme. Here are a few: The biggest issue with secure passwords is our memory, or our limited capacity for remembering passwords. We're pushing our memory limits as it is, and always working to devise new tricks to help better remember more secure passwords. This scheme introduces new ...


9

You're in luck, there is a good way to normalize this for publicly available information: WolframAlpha can be used to reduce strings into logical components that can be compared, and result in a more accurate Levenshtein comparison. Example for "Monday" Once you "factor" the string into all of its possible meanings (day of week, scrabble value, etc) you ...


8

Trust no one. Use secure strings to hold plain text passwords and hash them immediately. Gone are the times when you can hope your system is secure. It is not. It's just matter of time/money until a determined attacker can access your system. Even when traffic gets encrypted with SSL/TLS I can come up with several scenarios, each leading to passwords leak, ...


6

Your password not only protects your account, but also the whole community and the reputation of this site. - If many users who don't care about their accounts would just use "123" as their password some attacker could probably easily get access to a few hundred SE-Accounts easily. All kinds of SPAM-Protection could be bypassed by using verified ...


6

The general guidance is to use a char[], which while not foolproof, will allow you to overwrite the characters in the password once you're done with them, something that is not possible with strings, as they are immutable and continue to live on the heap until garbage collection. This has also been discussed in detail on StackOverflow.


5

The only property of a salt that is important from a security perspective is that it is globally unique. The length may impact how unique the salt can be, but is irrelevant from any other perspective. Assuming that it has a positive or negative effect on anything is to ask the salt to perform a function that it was never intended to serve. So, a salt should ...


5

I agree with Mike Scott's comment that it's best to use something which is already open-source which has gone through all the research and so on. If your doing the project for learning and personal usage then start off with basics such as: If you support clipboard don't forget to clear it during application been closed or after a set time period. Don't ...


4

A little test at the site you mentioned suggests they're considering length, alphabet, and brute force attacks only. The password you posted does indeed return an answer of 100 billion years. Changing it to "yummy candy yum" returns 'only' 49 million years. An eight character word, with or without numbers, returns eleven minutes. Adding one symbol ...


4

First of all, every stored password should be hashed with a different pseudo-random salt. Second, SHA-256 is not appropriate for storing passwords; instead, you want to use a key stretching algorithm, as has already been mentioned. There is a lot more detail at Crackstation. An encrypted hash is also called a keyed hash, and the key is sometimes called a ...


4

It's often still used for sensitive, powerful accounts on systems to which administrators even only get limited access. The password is created and stored by the security officer often and stored in a safebox which often requires more than one person to open. The accounts are mostly not used frequently and only in case of emergency.


4

Based on a google search of your hash it's a Dahua hash.Luckily for you it looks like it has some vulnerabilities www.exploit-db.com/download/29673/ I don't know if they fixed vulnerability and I don't really know much about CCTV systems.If that fails you could try bruteforcing the hash.


3

The Pros of a Password Manager: Reduces the friction for maintaining unique, strong random passwords for each application that requires them. Centralized account management in a digital form means that it's more portable, and easily backed up. Integrated tools for creating unique, strong random passwords means that you don't have to worry about ...


3

Provided that you mean Hash first (BCrypt) and then encrypt the hash, security should not be weakened, yet you are not improving security either. Encryption is, by definition, a reversible scheme. Since there really is no use-case for which you would require the decryption in this case, encryption is the wrong tool for the job. If you are looking use a ...


2

TL;DR: Rather write down strong passwords than remember weak ones. Always use unique passwords! Passwords for offline use should be stronger than for online use. You can use a password made of words if long enough, or take a long sentence and use all first letters as your password. For a password of a given length, a "random" string consisting of ...


2

As long as you are working with only online needs for the password for integrating with a system while the user is logged in, then you should store the passwords encrypted with both a database key as well as a derived key based on the user's password for your service. When the user submits the password for their login, you can use that to produce a password ...


2

If you need to retrieve the plaintext password at some point, then you indeed need encryption and not hashing (beware that many people call "encryption" what really is hashing). I suppose that your "business need" comes from the need to support some protocol where the server must know the plaintext password (e.g. the APOP authentication method in the POP ...


2

One advantage of the "envelope in a safe" method is that you can make use of Bruce Schneier's observation that society already has many well established and effective methods for securely storing small pieces of paper. In particular, there is an effortless process for securely doing an off-site back up to a trusted third party, namely putting another copy ...


2

Others have commented on the proper use of salts and passwords but maybe it's useful to add a word on hash functions because your question seem to suggest a somewhat incorrect intuition of the way they work. By design, a good cryptographic hash function should not let you guess how similar the inputs were based on the hashed values themselves. Otherwise, it ...


2

When you send unencrypted information on the internet anyone with access to the telecommunications lines or the networking equipment that sits on them can potentially read the traffic. That means the internet service providers which the traffic goes over, the telecommunications companies who supply the lines, and the governments who can compel (or pay) these ...


2

Traffic should be sniffed to get such thing. So the answer is Someone in your local network Local ISP Hosting provider However FTP can use TLS authentication which sends the login data encrypted. It is better to contact hosting provider and place you bought the domain and inform the issue.


2

You can login with Gmail or Facebook I believe. Then those rules apply. Why do they force us? Because they want to. It's not only that you worry about your account being hacked, but they might worry about your account being hacked. For you - 1 point SE starter - not really an issue. For SE - in your case - if you don't become an active user - not a problem. ...



Only top voted, non community-wiki answers of a minimum length are eligible