We’re rewarding the question askers & reputations are being recalculated! Read more.

Hot answers tagged

95

You are trying to solve a problem that you shouldn't have in the first place: Password Reuse The concept is simple. You think of a "good" password and use that for everything. Your bank account, online shopping, your e-Mail provider, etc. The problem is, if it gets leaked by any one of them, then all of the other accounts are potentially in danger. This is ...


61

You can't. The reason is that you can't trust the client at all. An attacker can modify the client as they wish, and circumvent any and all security measures you may have put in place. But what if we digitally sign our code? The attacker can't modify it then, right? Yes, they can. If you sign your code, the machine of the attacker needs to validate the ...


23

The established solution for this problem is to use different passwords for different websites along with a password manager. That way you won't have to reinvent the wheel. I know the rule don't invent your own crypto/protocol, that's why I want to know if there exists a know protocol for a client securing himself? Not every problem has to be solved ...


3

I used to use a browser extension which did pretty much exactly what you suggested. (It took my actual password + the URL of the site, hashed them together, and generated a password from that). It was great ... until eBay made me change my password because they had leaked their database. At that point, I had to remember which sites used one password, and ...


2

I'll only answer the crypto aspects of your reasoning; for discussions of the security implications of having a stateless master password, see other answers. Conceptually, your idea is good. It would be correct in the Random Oracle model, where hash functions have independant outputs for partially identical input. However, in the real world, our hash ...


2

"Client" and "server" can be vague terms if multiple layers (TCP, TLS) are involved. It is possible and even the most common case that only a single certificate is used inside the TLS handshake, i.e. one party is properly authenticated in order to detect man in the middle attacks. This party is commonly the TCP server but it might also be the TCP client. If ...


1

Such a man-in-the-middle attack is prevented by the use of TLS. RFC 6749, section 3.1 (OAuth 2.0 Authorization Framework) explicitly states that TLS MUST be used for the communication with the authorization endpoint. And even the introduction of RFC 7636 (PKCE) states the following when referring to the authorization request that returns the authorization ...


1

Given the clarification in the comment (should be in question, most important bit of information!), the answer is yes. Accidential modification is something that should in theory be quite unlikely as there is link-level CRCs in place as well as checksums in the TCP/IP stack. The theoretical chance of an accidentially modified packet passing the link layer ...


1

Your process is not OK. How can you make sure checksum is transferred correctly or hasn't been tampered with along the way? You need some sort of authentication before transferring file, a handshake! All this can be solved using SSL. You will not have to worry about anything.


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