Tag Info

New answers tagged

0

Not everything that is password protected can be hacked by brute force attacks. However, zip files can be cracked by brute force. Other systems have checks in place, like for example, lock out after three attempts, passkey verifications etc.


0

It depends. Most password cracking tools (oclHashcat, John the Ripper, etc.) support some kind of password "mangling". The most common types of changes will be things like CaSe VarIaTion, l33tsp34k, appending1 numbers2014, and the other kind of changes people commonly make to their passwords. So, given input like 'password', it might try 'p4ssw0rd', ...


0

Others have addressed the fact that you are violating Kerckhoffs' Principle. I'd like to suggest a way to recast your proposal that doesn't do so. Making your function be part of the key If we treat your "function that only you know" as part of the "key" then it is not a violation of Kerckhoffs' Principle. That is, we take your "key" to have two parts. The ...


3

a function that only you knew Well, such a beast does not really exist. Even if you can come up with some "mixing" procedure that lives in your brain only, it is quite hard to quantify how much that procedure is unknown to the attacker. If the said function exists as a script or executable file somewhere, or as a textual description on some blog post or ...


1

Ultimately, if the machine can use the saved password without specific human intervention, then... it can use it. This means that an attacker who gains full control of the machine (either an hostile software hijack with Administrator/root privileges, or he grabs the laptop and runs for it) will be able to recover the password. On a theoretical basis, if you ...


0

From a cryptographic standpoint people will tell you it's wrong to do so. It's certainly not "more" or "equally" secure, but I think it's secure enough. From a practical standpoint, for your personal passwords, it's not always feasable to remember passwords like A4q!qtrqFET4KmpVW.?T5"r'&141EFQFSq. If you force people to do so anyway you will end up ...


3

The short answer is No. This is a classic example of Security through obscurity which while it may work sometimes is considered a bad idea because it never works out in the long run. As in my answer to the other question it comes down to threat modeling. Consider the following two scenarios. 1) Attackers have downloaded a database of usernames and ...


20

[Disclosure: I work for AgileBits, the makers of 1Password] One of the reasons why I advocated an XKCD-like scheme (before it got called that) in Toward Better Master Passwords back in 2011 is precisely because its strength does not rely on the attacker knowing what scheme you used. If I may quote myself The great thing about Diceware is that we know ...


3

As others have said, the attack Bruce Schneier describes is effective when the user chooses multiple words him/her-self, not using a tool. Schneier usually writes to a general public audience, which is unlikely to grasp the difference between self-chosen "random" words and program-chosen random words. I'll add that even if you use a script or other tool to ...


3

It depends. One thing you need to understand is that this is not security-by-obscurity: the entropy values used in the comic assume that the attacker already knows you're using this method. If the attacker doesn't know how you're generating the passphrase, then the entropy goes up massively. The trick to the XKCD method is that you need to actually use a ...


31

Schneier writes this: This is why the oft-cited XKCD scheme for generating passwords -- string together individual words like "correcthorsebatterystaple" -- is no longer good advice. The password crackers are on to this trick. but the key to understanding what he is really after is a little further in his essay: There's still one scheme that works. ...


0

No, I don't think so. The actual advice in that xkcd comic are to use mnemonics that are easy for you to remember and generate password as long as you can remember them. Those are basic password advice anywhere, and will always stand true (even the quoted Schneier's method uses these two basic facts). Indeed, the comic makes use of common English words, but ...


-5

You need to use a lot of words to get the same entropy as with a pure random password. In the comic the entropy of the first password is cut down in half to make it work. 28 bit for a 11 character string. The comic assumes the password is "human generated" while the words are random. Hint in the comic: "To anyone who understands information theory and ...


1

I'd also like to add a yes answer also, but for other reasons. It's not a good advice [in general] because of length constraints: Sites like Skype, ING, eBay, and in my country Binckbank ans KPN limit passwords to 20 characters. (That bank limit is 15, but it used 2 factor authorization) With an average length of 4.5 characters/word for a short 3000-8000 ...


84

The Holy War I think you will find that the correct way to generate passwords could start a holy war where each group thinks the other is making a very simple mathematical mistakes or missing the point. If you get 10 computer security professionals in a room and ask them how to come up with good passwords you will get 11 different answers. The ...


3

The strength math is quite simple if word choice is at random: (number of words in dictionary)^(number of word in the sentence), assuming the attacker knows the number of in words. So a 5 word phrase using a known (by the attacker!) 7776 word Diceware dictionary: has 7776^5=2.8E19 or 64 bits of entropy. There is one item that is not mentioned in the scheme: ...


32

The XKCD password scheme is as good as it ever was. The security doesn't derive from it being unknown, but from it being a good way to generate memorable passwords from a large search space. If you select the words to use rather than generate them randomly, though, this advantage is lost -- humans aren't good at being random. The bit about memory is ...


0

Please note that Microsoft Office IRM is not intended to secure a document. It's intended to manage rights, but does not use strong encryption and should not be exclusively used for sensitive documents (it's like a lock on a filing cabinet - you could pick it easily, but it's there to let you know you shouldn't). There is no feature currently in office that ...


1

This is exactly what Microsoft's IRM (Information Rights Management) product is designed to address. However, as pointed out by others, the file on its own cannot achieve what you are trying to do, so you will need some infrastructure, which MSFT calls the Rights Management Server (with the delightful irony of being Rich Stallman's initials). And this ...


1

This is no a good idea vs using a password manager and actual strong passwords. If you "hashing" algorithm is able to be done in your head, then it simply is not secure and WILL be vulnerable to fairly simple analysis attacks. If it is complex enough to require an application with multiple iterations, it may or may not be vulnerable to simple analysis ...


2

Yes, you are correct. Anywhere on your site where it can be confirmed that a username exists or not can lead to username enumeration. However, this problem can be solved if it important to your system. Within some systems, username enumeration cannot be avoided as it is inherent to the nature of the application. One example is a web mail service - here ...


3

It depends on what the user name is. There are three main approaches for user names: User selected name Email address Assigned user name - usually a string of digits You are correct that for user selected names, an attacker can use the registration process to infer what names are in use, so there's limited benefit to the login returning a generic ...


1

You cannot make a weak password stronger without using some additional entropy source. Hashing it does not add any entropy and therefore the resulting password is just as weak as the one you started with. Also using some "secret" hash algorithm is a bad decision since you are basing you security purely on keeping the algorithm secret. This means you cannot ...


6

Don't roll your own crypto. It lulls you into a false sense of security, and may be detrimental if you publish it and other people start using it. A hashing algorithm's strength does not stem from the opacity of its design; on the contrary, it benefits from the thousand expert minds looking at it. Your basic idea isn't without merit, though. But if you are ...


5

if your hashing algo is irreversible and secret This is always a bad design practice. As soon as this algorithm becomes known to the attacker (and it will), you are doomed. Thus all designs should assume that algorithms are known to the attacker. Keys should be kept secret, not the algorithm -- keys can be easily replaced, but algorithm cannot. Please, ...


1

Not all systems have account registration. For instance, your operating system login does not. Websites do stop accepting new members from time to time. It's a question of separation of concerns: should the login dialog query the system configuration and customize its behavior based on whether the system is configured to accept applications for new accounts ...


0

The common argument for vague messages seems to be to prevent attackers from guessing valid usernames. There's actually a simple solution that doesn't severely impact legitimate users, and should be in place anyway: restrict the maximum number of failed attempts in a period of time. By restricting attempts, you prevent all brute-force attacks. Say you only ...


-1

I am trying to put my attacker hat on and I see 2 cases: Your site has a registration page (such as gmail or stackoverflow). I could use the registration page to figure out the user name of an existing user by brute force. Or I could just create a new user. My new gmail or stackoverflow user will probably have about the same rights as the one I would ...


27

You're making the assumption that the system actually knows which field was entered incorrectly. There are several reasons this is not necessarily true. One possibility is that it's a side effect of implementation. A simplistic method of looking up logins in a database might look something like (using :n for parameters supplied by the user): SELECT 1 ...


-1

A smart website would have a captcha on their registration page to prevent this sort of thing. But you know how 99% of websites are. They will ruin their UX with a generic error message, even though it doesn't give them any extra security. Personally, I don't bother with generic error messages since there are plenty of other restrictions in place for my ...


40

No, you are correct that at some point during efforts to prevent attackers from determining valid user identities you will either have to lie to them or provide exceptionally vague error messages. Your app could tell a user that "the requested username is unavailable" and not be specific as to whether it was already in use or just didn't meet your other ...


9

In general, it is harder to brute force a registration page than it is to brute force a log in page, so we benefit from this additional cost. But, in concept, you are correct. There are other ways to enumerate usernames than log in page messages. It is simply 'Good Practice'(TM) to keep log in failure messages generic in order to make it harder for ...


4

Assuming your system is using regular simple unix authentication, there's at least one way of changing a password assuming you have root access. You can do this by simply editing the /etc/shadow file and pasting in a new password hash in place of the old one. This does not influence "chage -l" output as the change is done outside tools, so no other data ...


0

Here are some papers that you might be interested in: "Password Managers: Risks, Pitfalls, and Improvements" (2014) Abstract: We study the security of popular password managers and their policies on automatically filling in passwords in web pages. We examine browser built-in password managers, mobile password managers, and 3rd party managers. We ...


1

As a follow up to David's answer I wanted to point out this article (I can't add a comment): http://digital-forensics.sans.org/blog/2012/02/29/protecting-privileged-domain-accounts-lm-hashes-the-good-the-bad-and-the-ugly It shows that even when clients are told not to store LM hashes in the SAM database, they will still be held in memory and can be dumped ...


0

Use multiple factors authentication, there are many options. Yubikey is the simplest - http://www.yubico.com/products/yubikey-hardware/yubikey/ And there're a lot of similar devices, just look for "authentication token" There's even a more strict approach which is if you want to secure your password - don't use it at all. like this ...


2

I agree with @schroeder that password reset emails are one of the areas where it tends to be more acceptable to instruct users to click on links. After all, the user was the one that triggered the password reset and should be expecting an email. You could add text in the email that says "This email was sent due to your request. If you did not request a ...


2

The token is just to verify that you received the email, that you own the account. Password reset links in emails are a convenience that provide proof that you own the email account and allow you easy access to the password reset workflow. These tokens don't have to live anywhere for long term and you can invalidate them after some missed attempts if you ...


5

https must be enabled anyway and you must not use http in your login form. What your developer is saying that by limiting the application to be served as https only (should be configured in the web server) even if the password is sent in clear text in the form, the whole traffic is encrypted and hence the password is safe. That is correct. Even if you hash ...


4

From the attacker's standpoint, whether you send a plain text password or a MD5 hash or it doesn't make much difference, as long as sending the same value over again unlocks the door. Remember, getting in is the primary objective, not obtaining the exact value of the password. So if the attacker intercepts the hashed password, sending it again from his box ...


-1

In my opinion sending a cleartext password is a bigger sin and risk because the hacker will need less expertise (i.e sniffing the cleartext password from the server) as compared to using javascript (the hacker will need more expertise). and also, why not secure your cookies instead? like to not mark your cookies as httponly?


4

I would recommend against using sha256 for hashing passwords. The sha2 suite is designed to be fast - exactly the thing you dont want. In short, use bcrypt: http://stackoverflow.com/questions/4795385/how-do-you-use-bcrypt-for-hashing-passwords-in-php In a proper KDF, iterations are similarly included to slow down the process of password hashing (to answer ...


12

actually, hashing it MANY times is bad. here is a quote from http://yorickpeterse.com to proof that. "To cut a long story short, hashing a hash N times doesn't make your passwords more secure and can actually make it less secure as a hacker can quite easily reverse the process by generating hash collisions." read the full explanation at ...


2

The security gain from hashing 90,000+ times is basically minimal.In fact it's actually less secure since any prospective hacker can crack it easier by looking for collisions. You may as well use a higher hashrate (i.e sha512) and therefore have a longer hash rather than just looping through and appending previous results. All your loop does really is ...


0

This topic has really been discussed to death, so this is only the short version. Salts have several benefits. The most important one is that it forces an attacker to break each hash individually. Without salts, the attacker needs to go through his list of possible passwords just once. For each item, he calculates the hash and checks if it matches any of ...


0

If you do have such a question, don't post it here with your own name and picture! Better create an anonymous account so there is no link between your name and your password strategy.


3

This topic is documented extensively all over the web as well as on this site, so taking the time to do some research on your own would have been a much faster way to get answers. However, if you're just having trouble understanding the concept a simple explanation may help. Simply put, it alters the hash of a password so that it does not physically match ...


1

It's impossible to protect some file for some time. Intrinsically, the file doesn't have any property that will allow it to know whether it's January, 1st, 2010 or 30-Feb-2050 (if February will have 30 days in 2050). What "could" know the time is the program opening it. In your case, Excel. But a program itself doesn't know about time either. It would need ...


2

A file is just a collection of bytes. It cannot do something to itself on its own. You need an access restricting application, or use what is available. Because it is an excel document, any weird solution you come up with can be circumvented just by saving it locally unprotected or copy pasting. But if you still want to at least try, even if it isn't ...


0

Unless you specifically enabled full device encryption, merely setting a device password does not encrypt the device. Hard disks have supported passwords for decades, but have not had encryption capabilities until recently. These passwords just won't expose the raw device to the BIOS until you've unlocked them, but the actual data remains unencrypted.



Top 50 recent answers are included