New answers tagged

1

The answer is adding --continue-on-success


0

It is absolutely a good idea - you'll probably have an initial ramp of hatred from the users who were used to installing whatever they want, but once this dies down you'll be a lot more secure. You'll want a good way to push software (or let the helpdesk do it remotely) before you start this. You'll also want to make sure that people don't just swap to ...


3

Custom header (or custom use of the Authorization header, or technically you could use Basic auth but please don't) is the only option... if it actually needs to be a GET. Why should it, though? You already control the API and the client. Just make it a POST request and put the credentials in the body, same as every login flow. The critical thing is to keep ...


1

What about high-entropy secrets? Is it sufficient to salt and hash them with a normal modern hashing algorithm or should I still use a password-hashing-function to increase calculation time and memory? Example: User uses a cryptographically secure RNG to generate a 256-bit secret which he then uses as 'password' to sign up. Is it good enough to store a salt ...


1

This is the well known security/cost balance for the choice of a hashing algorithm: the more resource consuming the algo is, the more resilient to brute force attack [assuming the hash has been leaked] the less resource consuming the algo is, the more users can be accepted on a server When you have a stateful application, the common assumption is that the ...


0

It depends on the quality of other secrets of that type. If the secret is high entropy, but it's stored as a password and other secrets are typical low entropy passwords, then you should use a normal password hashing function like Argon2. That's because you don't want to make it easy to guess the weak ones, even if there are strong ones like the ones you'...


4

No. Nothing you do with a computer is 100% safe, and nothing in life is 100% safe. That's the wrong way to look at it. The question you should be asking is, which option offers more safety? When planning how to secure your system, you want to follow a defense in depth model: At every point while designing or configuring your system, you want to ask the ...


9

I think the title to your question and the body of your question are contradicting each other a bit and I think that may be leading to some of the confusion with the other correct answers. Your title says "Is it really safe" but in the body of your request you're comparing passing data via stdin vs command line arguments. When you compare two ...


1

You are missing quite a bit. First, you need to rotate passwords from time to time. That leads to exceptions in your rules after some time. You will end up with unchanged passwords for sites where they don't expire, sites with a 3rd version because the passwords expire after 90 days, sites where they expire twice an year, and so on. Sometimes you will forget ...


19

The important part is not about an attacker compromising exactly your account. Any account on a typical Linux system can run ps and see what others are running. Even if your particular machine is personal and has a single (human) user, a typical modern Linux system has ~25 accounts created for internal use (just look in your /etc/passwd). They exist for a ...


0

When it comes to security, the rule is do not roll your own. Entropy evaluation, bias identification, and side channel attacks prevention are very complex things. If you want good random passwords, just use a good password manager like keypass. Let it provide random passwords and store them in it. You will get fully unrelated passwords for all the sites or ...


40

In addition to the different permissions needed for a process' command line vs its pipes, consider: Command lines often show up in audit logs, shell history, or similar; data passed to stdin does not. Command lines are visible at any time from when the program starts to when it stops (which can be a very long time) even if nothing logs the command line or ...


59

/proc/<pid>/fd/0 can only be read by the process owner and root. /proc/<pid>/cmdline can be read by all users.


1

Does not sound like a good idea to me. Benefits of using a cloud-like solution: your passwords are synchronized and backed up automatically. Drawbacks: you need Internet access whereas Keepass works offline exposing your passwords to hostile actors including authorities that can subpoena for the data In case you are subject to an legal investigation in ...


1

I know that Google is a serious company, and I would assume that they use good security practices. Nevertheless, storing your passwords on Gmail means that they are accessible to Google, which includes Google admin staff and US governmental agencies because of the Patriot Act. Being a non US citizen, I would never store my professional account passwords ...


1

There is a strong difference between both ways. Never logging out is only possible under 2 conditions: you manage to keep the cookie in the browser client side - it may not be that easy because session cookies are normally non persistent ones the server never expires the session - which would be a true security error (1) or you maintain the session active ...


1

Probably good enough as a bare minimum, but there are a lot of improvements that could be made, and it's under-specified. A few specific points to consider: PBKDF2 is an older algorithm, and its lack of memory hardness means it's easy to parallelize, which helps with cracking attempts. I'd recommend using something newer (in descending order, argon2, scrypt,...


1

It's pretty hard to tell whether it is safe by these three points as it also depends how you configure these with other part of your app. But if possible, I would suggest 2FA for authentication. Apart from this, I would suggest a few things you should be aware of: Make sure you follow the JWT security practice (e.g. none algorithm shouldn't be allowed, ...


3

The traditional way when entering passwords was to give either no feedback at all or to give a replacement character instead of the real one, typically a star. The idea behind this is to make shoulder surfing harder. But it of course impacts the usability, i.e. the user cannot easily see if they entered the wrong password. Because of this usability issue in ...


0

Some password entry fields don't supply placeholders either. Reasons to not give feedback during password entry: Observers can use this to help guess the password. Implementing a feedback mechanism in the UI is extra code. Traditional password entry mechanisms did not have a complex UI. Reasons to give feedback: Some users are confused when nothing ...


1

As you noted, the current recommendation is to do this, and there exist both lists and APIs (e.g. from haveibeenpwned a.k.a. HIBP) to support this. It provides much stronger protection than simple "complexity" rules (which often lead to a false sense of security, or even using weaker passwords than one otherwise might, because the extra changes to ...


1

Hmm..., this is not a stupid idea: we are already used to constraints about a minimal password length or a minimal number of character classes. Having a black list for passwords known to be present in lists used by password crackers should not unsettle too much users. IMHO, the real problem is that those list could change rather quickly. And the rule if ...


0

I don't know why but there is a sort of problem with John the Ripper, I uninstalled it with: brew uninstall john And I install another version of it named john-jumbo. brew install john-jumbo Now it works perfectly. Ps. --format=md5crypt doesn't work with my hash so I used --format=raw-md5.


5

KeePassXC developer here, I got directed to this thread and want to add some remarks. The answer by Jeffrey from 1Password is technically accurate. The YubiKey is used in a mode which is slightly different from what it was designed for. KeePassXC presents a (pseudo-)random challenge (the database's master seed, which changes every time you re-encrypt, i.e., ...


0

That's not the correct format for an md5crypt hash. They typically start with $1$ - you can see examples of the various md5crypt formats that John accepts in the source code. When John reads your input file (hash.txt), you're telling it to only look for hashes in the md5crypt format - so it ignores the line in the file because it's not formatted correctly. ...


0

You're trying modify an existing entry. The error message you provided indicates that you tried to add a new entry. You should use CLI tool ldapmodify (instead of ldapadd).


Top 50 recent answers are included