Hot answers tagged

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 ...


39

This source says that it is almost impossible to avoid user enumeration in this situation and delaying an attacker is the best you can do: If you are a developer you might be wondering how you can protect your site against this kind of attack. Well, although it's virtually impossible to make an account signup facility immune to username enumeration, it ...


33

There are two reasons to ask if your password is being encrypted: You are worried about the security of the site. You are worried about the security of your password. Regarding site security, with no HTTPS, there is effectively none. You should consider every communication with the site as public and assume that an attacker can pretend to be you. Just ...


20

What you got there is 232 hexadecimal digits, or 116 bytes of data. It is not a plain text string in any normal encoding. It could be a hash of your password, it could be your password encrypted, it could just be some kind of easily reversible obfuscation. Or it could be something completely different from your password, like a session identifier. It could ...


18

The alternative to allowing multiple users to have the same user name is far worse! Really what happens with that system User requests a new password You now have to check passwords to make sure no collisions happen The user can use this to brute force other accounts That's bad. So you need to prevent multiple users from having the same username. You do ...


13

In a corporate environment, there are a few places you can look. Company Acceptable Use Policies generally will have a clause saying not to share accounts or disclose passwords. If your company is subject to certain regulations (PCI-DSS, SOC2, HIPAA, etc.) they will have similar requirements. Because you want to communicate with your boss, there is a ...


9

When a user tries to log in, he or she enters their username. When registering, you are told if a username is taken or not. If you find a taken username, you can try to log in with it and possibly hack it. Solution which is also another problem: If they had to log in with an email, the knowledge if a username is taken won't help - you log in with an email ...


8

The first rule of crypto is do not roll your own crypto. You are trying to come up with a new solution to an old problem where established best practices already existst. That is a bad idea, since even if you are a security professional as a human you are likely to make mistakes, and your untested solution will go through much less review than already ...


7

When you want to eavesdrop on the communication between your web browser and a server, you can often do that with the developer tools of your web browser (usual hotkey: F12). Most browsers will have some kind of Network tab where all network communication between the current website and the internet is logged in cleartext. When you find your cleartext ...


6

An authoritative single source for this may be hard to find as it is, ultimately, subjective. However, not sharing credentials is a fundamental expectation of our current computing paradigm. The use of logins and passwords is fundamental to this reality and to step out of this violates that paradigm and every system that has been built around it. Access ...


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 ...


4

Since you know that your plaintext tokens are unique (or at least this is a logical inference) you don't need a salt. The salt's intention is solely to provide hash-uniqueness in the case of identical passwords, but since your input space is intended to be guaranteed unique, you don't have this problem. Additionally, since you have control over the ...


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

Allowing a user (or an attacker) to find out whether usernames exist or not is known as a "username enumeration" vulnerability. This is summed up well here: As an attacker if I can use your login or forgotten password page to narrow my list from 10000 targets to 1000 targets, I will. You can add "sign-up page" to that list. This aids an attacker in ...


3

You can use bCrypt. The simple solution is sending your user a an Id and the Token: https://example.com/pwdReset?resetId=123&resetKey=[your long randomly generated key] You can lookup the hash using the id (just like you would use the username to lookup the user's password hash).


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 ...


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 ...


2

Risks of Exposing Encrypted Information With it being encrypted I assume having it publicly accessed wouldn't affect security as the encryption setup would make it pointless for anyone to try and decrypt it. Your encrypted information will stay private as long as the crypto works (no flaws in the underlying mathematical principles are found), the ...


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.


2

You'll need to find a secure channel to exchange the new password over. Communicating verbally would work just fine. As to an automatic notification, the only way to do this would be to flash your router with custom firmware which would allow you to write scripts to add functionality, such as DD-WRT. However, DD-WRT is unsupported on the Huawei WS319. As ...


1

There are good answers from @SilverlightFox and @MaxTheBackspace. I just want to make one thing clear again: It should not be possible by default at any point in the application to let users enumerate a (likely) global unique identifier like an email address. Not even ONCE. Not with IP address monitoring and rate limiting and a CAPTCHA in Klingon language ...


1

This is how normally you investigate this. If it is a hash of your password, then you could test your password with the hash function and compare the output. This particular (assumed) hash string has 232 hex-digits, which equals to 928 bits. This is the exact size of RSA-280 number, which is used in SHA-1 encryption (along with many other RSA numbers, so you ...


1

chage -M 99999: The password will be valid for 99999 days (until 21 feb 2290 if changed today) chage -M -1: This will remove the checking of the password's validity. So, unless your users are quite longlived (and are not going to change your systems passwords)… no, I don't see any functional difference ☺ That security scan doesn't seem too thorough.


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.


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

Yes, they need your plaintext password to make the VPN work, simply because their service is badly configured. They shouldn't need your password in plaintext. The problem is that they use your plaintext password in their authentication procedure. When a new user creates an account, the VPN provider should properly hash their password and use that hash to ...


1

We are aware of the needs of sharing passwords and confidential information in Confluence. Since it's a center of our team collaboration it would make sense to share information through Confluence. I'd recommend evaluating the Security & Encryption add-on which provides a macro to encrypt (with PGP) and store your passwords.



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