New answers tagged

0

According to this, it is possible but not secure or recommended to ask the user for a password in a custom login screen, what I can understand. The main reason for that being frowned upon is because you don't want users to get in the habit of typing in their passwords anywhere other than their respective websites.A malicious website could ask for your ...


1

Because it is stored as a one-way hash - since Amazon know how long the OTP part, is they trim that off what you typed before generating the hashed version to compare with what they have stored.


2

The password is not hashed in the application but in the server. The server gets the password+OTP token in clear (protected with HTTPS between client and server) and can extract both password and OTP token from this, then proceed with normal password verification.


0

(should be a comment, but its a bit long) What is your question here? Are you looking for an appraisal of this? Ar you planning on implementing it? Every system I have come across which uses authentication also uses authorization. That means that a user identifier always exists separate from the token proving the identity. Certainly there is nothing to ...


0

Symmetic encryption using the user's password as key This is the base of a correct solution. If you want to store it securely, you need to encrypt it with a key you don't have. So that leaves the user's password. To solve the problems, you just need more layers of indirection. Shared lists are encrypted with a single key, and that key is in turn ...


3

Could ...? Sure. I think you meant Should ...? No, one shouldn't rely on QR code. Using QR code is similar to writing password on a sticker, but is even worse. The major difference is, that QR code is designed to be easily read by phones. QR code can be duplicated. For instance, when you are waiting in line, many people around you can easily make picture of ...


3

Your account is as secure as the weakest password able to access it. If one password is K_ig6W952B[1DGF3&8q.V^-}0ZN?rbDZ and the other password is Despacito2, then the effective security is almost nothing. Assuming that both passwords are equal, there are still twice as many passwords as usual, meaning that a hacker attempting to crack hashes for your ...


0

Based on my understanding of how ProtonMail manages keys, the answer should be no. As you mentioned in your question, your private key (which is used on the client side to authenticate with the system and decrypt your messages) is encrypted using a key derived from your password. Then, this encrypted private key is stored on ProtonMail's servers. If you ...


1

You could do both, you hash it at the client so if the attacker can get through the https security they will not be able to see the plain text password. Then hash it again at the server so if the attacker gets the passwords stored in the server he can not just send that to the server and gain access to the password.


1

I think you are confusing two independent concepts. Full disk encryption protects a dead system, that is a non-running system. Once the system is running, FDE is no longer relevant. The running system has the same password risks and requirements as any other system as FDE no longer protects it.


0

this is going to be answered by measuring the potential for entropy which is determined by your character library. Taking words and making them numbers is only going to be good when it ends up making for a longer password. You would be better off going in reverse and substituting every numeric and special character used in a password for an alpha character ...


1

Yes all passwords should have a standard that enforces a high level of entropy. If not for any other reasons than these two things: Contributing toward the randomness of the password hash via the source password, and secondly the principle of defense in depth. It is foolish to rely on single layers of defense against compromise. In fact I would argue that ...


1

There are a few reasons why you'd still want complex passwords, though, they're all a little situational. Local access or theft of your machine while it's on (or in sleep mode) but locked. A bigger problem for laptops or workstations in open offices/public areas, especially if you don't disable normal sleep and go straight to hibernate. Remote access via ...


2

tl/dr: This method hurts your password strength quite a lot due to the loss of characters (mainly since 0 and 1 are often left out when entering letters through a numeric pinpad). However, trying to brute force a password here is slow, so with a long enough password you'll be fine anyway. Analysis You already seem to know the answer, but I'll spell ...


1

With any question like this it's all about risk mitigation and usability. The first thing to accept is that if a third party has unrestricted access to hardware you won't be able to stop them. The same largely goes for having root access. At some point a secret will have to exist unencrypted in memory, and at that point it is possible to retrieve it. So ...


3

OWASP comments on this in Cleartext Passwords in CATALINA_HOME in the context of managing Tomcat's web server database credentials. Their view can be summarized as best practices is to never to store clear text passwords, but it is very difficult to avoid Their primary recommendation is to use file system security to secure the credentials file and ...


4

This already exists. OpenPGP has "authentication" as a possible key usage, and a PGP key can be used to authenticate an SSH session if gpg-agent is used in ssh-agent mode. I use that daily as a single-sign-on solution with a smartcard, but there is no reason why this wouldn't work with a regular key. There are also various plugins that allow signing ...


5

An alternative approach that implements the same concepts is SRP. Ignoring the math in the protocol, the idea is that when a user signs up the client generates a password verifier which is sufficient to verify credentials, but not to act as them and sends it to the server to store. At login time the parties then exchange messages based on random values that ...


4

While the scheme described in the question has a significant problem in enabling offline bruteforce attacks against the password, it is possible to redesign it without this vulnerability. For example, one can generate private key directly from password. That avoids the need of storing the private keys at all - basically the password becomes the private key. ...


11

As the others said, private keys aren't shared. full stop. Otherwise, they are called public keys. But: Cryptographically signing on is pretty standard. HTTPS supports that: Authentication using HTTPS client certificates; and all modern browsers have the built-in means to generate the necessary keys when asked to. Your problem has already been solved; ...


66

You should never try to secure a "real" web application with a scheme that you invented on your own. As such we shouldn't discuss practicalities on how you would actually implement or use such a method. Will it work? Your scheme does not send a password over the wire. What immediately jumps out is that you send the private key to the server, which never ...


5

As Anonymous said, the private key must always be private. Sending the private key to any entity negates any security provided by your login. Basically, what you are designing is called Challenge Response Authentication, and can be done even without a keypair: One party (the server) generates a random token and sends it to the other The other (the client) ...


-3

Also, if the attacker didn't gain control of the account, why use it to enroll in all these services? First of all, some of the spam you are getting might actually be phishing attempts to lure you into revealing your password. Second reason, and maybe the most obvious: since all those sign-in attempts generate security notifications, the hacker obviously ...


9

While I like the idea of PGP for login, this is not the way it's supposed to work. The private key should remain on the client side, always, and never be shared with anyone. This setup encourages bad practices and provide incorrect education about PGP. What you could do is, have users upload their public key to the server, and then you present them a ...


6

The use of your email to sign up for services might be a coincidence and not being done by the party who logged into your account. I get a dozen of these types of "mistakes" a week from around the world due to my fairly generic email account. So, this set of events might not relate to the person who logged in. However, there are a couple of scenarios that ...


3

I know you quickly dismissed Apples own Keychain but I'd like to make a case for it and help guide you in the right direction of how you can use it via terminal. It’s protected by 256-bit AES encryption. It's backed up on cloud servers. You can use it to store secure notes. Locally the keychains are stored in ~/Library/Keychains/ and /Library/Keychains and ...


2

As far as I am aware, MFA only protects your login to the GMail web mail service. If the attacker could successfully guess your password and you have IMAP client access enabled on your GMail account, he would still have had access to your emails up to the time where you changed the password. You should definitely review those access settings, check the trash ...


0

Question 1 You need to store all the information, but you should store it encoded in a single column. You probably already get the encoded output from your hash library. It should look something like this (source): $argon2i$v=19$m=65536,t=2,p=4$c29tZXNhbHQ$RdescudvJCsgt3ub+b+dWRWJTmaaJObG To understand what the different part means, see this question. ...


0

It very much depends on who else has access to your machine, but putting a file on your filesystem and restricting access to that folder with chmod 400 is a pretty good first step. You can use secret managers like lastpass and keypass as well


0

If we assume that the method described by Randall Munroe in this XKCD comic strip is sufficient, then we can determine how many emojis you neeed to make a sufficiently strong password out of only emojis. And as it turns out, emojis are quite comparable to words. There are 3,178 emojis in the Unicode standard (~11.6 bits), while Munroe rated each word at ...


2

It is very hard to evaluate the quality of a random password generator without knowing its underlying algorithms. The quality (the entropy) depends essentially on 2 elements: the number of possible combinations the equivalence of probability of different combinations The problem is that a random generator that would iterate over 10 millions random password ...


0

First off, no password generator on a website "secure" in any sense - unless you read the source code and host it yourself. Second, the only requirement for a password is that it is sufficiently random. You could perform statistical tests for randomness, but that would require some knowledge about the composition rules to be meaningful (e.g. does it always ...


96

Should I be concerned about this? Yes. This should be of concern to you because an attacker was able to obtain the valid password for your Gmail account. From the details of warning you have provided, it looks like it is from fraud detection rather than an OTP failure. If it was an OTP failure, you would have received an OTP when that login attempt was ...


3

You shouldn't be concerned. Just as you said yourself, the attacker was blocked and you have changed the password. There are, however, some actions you should take: Verify that the discovered password does not hint at any other password you may have used anywhere else. Harden passwords of other accounts you hold that the attacker may deduce from the ...


0

On 64-bit machines the maximum integer value is 0x7fffffffffffffff (9,223,372,036,854,775,807), and in a random number generator which is not cryptographically secure the seed value will typically be an integer in this range starting from 0, so it should be clear given this number of examples in a very simple generator that patterns could be spotted. You ...


3

There is quite no case when it's not easier for the adversary. The only case is if the password is salted (with large random) and the salt is not displayed. The main concern is to know how much easier it is for the adversary. In the worst case, he can perform offline dictionary/bruteforce attack and due to the dispersion of the hashing function, he ...


0

I do think there are some benefits to this, although it is unclear if the reward is worth the trouble. There isn't much of a "factual" answer to this, since it is really up to you how much effort you want to spend. It is widely known that modern desktop OSes pale in comparison to mobile when it comes to end-user security. On your computer, your web browser ...


27

TL;DR: The answer depends on the hash algorithm, what part of the hash is revealed and the strength of the password. Assuming that the hash algorithm is known the knowledge of a specific part of the hash might make brute force attacks easier: The attacker might now run most brute force tests offline and also in parallel and is thus not restricted by rate ...


1

There is no problem if you have a good password created by diceware or Bip39 with good entropy then a polynomial-time adversary even with the knowledge of the hash and salt cannot do anything. If your password is already 123456, we already assumed that can be broken, part of it leaked or not. What about the salt is not available to the attacker, good luck ...


9

1) password hashing iterations If you don't care about waiting a little longer, you can use the maximum count value, which is 65011712. This isn't strictly the number of iterations so much as the number of bytes to be hashed. S2K works by repeatedly feeding the password and salt to a hash function for a specific number of bytes. The more bytes, the longer ...


2

It's not exactly efficient and my gut feeling is it may increase attack surface. General browsing on generic sites means the potential for vulnerabilities to be exploited firstly on the website to serve malicious content and secondly by your client to be exploited. With your setup, it would mean exploiting Firefox to run privileged code that exploits an ...


5

As a general rule, the server should not provide information about a submitted password, regardless of if that password was correct or not, back to the client. After all, humans tend to reuse passwords, so even if the password isn't correct for that user on that site, it may be correct on a different site, such as their bank. I'm not aware of any ways to ...


0

This usually isn't a way someone could get your password. The only way I could think of is that someone can copy and paste the password out of the field. But I think this is blocked by most systems by default.


0

I don't see severe risk with this, but as an attacker one can recover your previously typed password using developers tool (changing type=password to type=text) and can get idea about your password setting pattern.


0

This is exactly the problem that hardware security modules (HSM's) aim to solve. An HSM has its own embedded processor, and contains one or more private keys, which never leave the HSM. Hence, the private keys on the HSM are inaccessible to programs running on the machine that the HSM is connected to. The HSM can be used to authenticate with a server, ...


3

no matter how I handle the api["secret"] it ends up on RAM which can be dumped by malware and uploaded to an attacker. ... How can this be avoided? It can't be. There is a fundamental contradiction between the requirement to use the password for a computer-based authentication step, and yet to want the computer not to have access to the ...


3

I think you need to realise that you have 3 secrets here, from your perspective: the password the algorithm, and the hash length You assume that the password can remain intact, the algorithm can be exposed as an acceptable risk, but you are afraid that the exposure of the last one might defeat your security and the other two secrets. This is a rookie ...


1

There is no generic answer to this. It depends on the actual hash and encryption algorithms and whatever "multiple times" and "fewer" actually mean. But I think that the general idea of this approach is wrong. Instead of trying to add security by doing hashing/encryption multiple times you should start with a known strong key derivation function (and not a ...


Top 50 recent answers are included