New answers tagged

0

The important question here is wheater you trust your company or not. If your company isn't trustworthy they could easily steal your password without a certificate (e.g. by using a key-logger). If your company is trustworthy the fact that they have installed a certificate on your system doesn't matter, since you trust them anyway. Should the fact that ...


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


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


0

This isn't generally a serious concern unless your usernames are email address, which would permit the spamming or phishing of your users. (Or also potentially if you provide a messaging API.) That said, if you feel like the underlying username needs to be a secret: Let new users choose a display name, but don't allow them to choose their underlying ...


-4

Well, the first thing I have to say is what I say to just about anyone asking username/password questions: stop that. Use OpenID and get out of the username/password business. Secondly, usernames should be looked at as a hash collision mitigation, not as security -- i.e, two people with the same password. From a security POV, you should consider the ...


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


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


0

Enumerating usernames is a threat because the combination of username + password will give an attacker access to the account/system. How much of a threat that is depends on your system. For example, in a forum where the username is anyway attached to every post, that threat is very low. If you enforce strong passwords, it reduces the threat. In your ...


0

From a user interface / usability perspective, if I've already taken 3 steps (email, phone/ recaptcha), then that reduces the likelyhood of a machine attack, and any further roadblocks will reduce the number of people who want to sign up but give up in frustration. I personally don't mind at all if I try to choose MarkyMark (No, I'm not the rapper), and if ...


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


0

It may be a better practice for the login process work with an email and not a username. If you need to have a username by not making it a piece of authentication an attacker can no longer use the username availability check as a malicious tool. At this point the username is just vanity and public facing identity. I know in a comment you stated you wanted ...


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


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


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


0

I would store them in an encrypted password vault (Somethg like Dashlane, Lastpass, or 1password.) in the notes section. It will be able to synchronized via mobile and encrypted also. Assuming you aren't using the same password as your master password you would be safe.


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.


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


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


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


0

There're two possibilities, your password is either encoded or encrypted into that string. If it was encrypted, then it can only be decrypted using the key defined in the webapp, which is quite secure and need a long time to try breaking it.


0

The larger the password the better; however, if it is long, and you forget what the masterpassword is, or you lose access to the text file where this is stored, you are in big trouble. In addition, signing in on a mobile device can be a pain if the password is long (unless you send it to yourself, which is a risk). So, as a result, I have found that around ...


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


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


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


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.


-4

No, there cannot be an authoritative source because the statement is not true. There are times when you should give your password to other people. There are plenty of scenarios where the benefit of providing your password to someone is greater than the cost of the worst case scenario of providing them your password, and where logging in for them is made ...


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


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


0

This is how I would do it. Have the web app generate a public/private pair (say DH). Show the public key on the screen as QR code, the user then scans it with the phone. From this point onward, the phone can send anything to the web app securely.


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

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.


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.


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


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


0

Here is a list of tools I evaluated for us. sysPass sysPass is a PHP web based Password Manager for business and personal use. AES-256 encryption in CBC mode RSA for sending passwords from forms Two factor authentication HTML5 and Ajax interface Users, groups and profiles management (up to 20 access levels) MySQL, OpenLDAP and Active Directory ...



Top 50 recent answers are included