Two-way password encryption without ssl

后端 未结 13 1518
感情败类
感情败类 2020-12-30 05:01

I am using the basic-auth twitter API (no longer available) to integrate twitter with my blog\'s commenting system. The problem with this and many other web APIs out there

13条回答
  •  再見小時候
    2020-12-30 05:33

    APIs and OAuth

    Firstly, as others have said, you shouldn't be using a user's password to access the API, you should be getting an OAuth token. This will allow you to act on that user's behalf without needing their password. This is a common approach used by many APIs.

    Key Exchange

    If you need to solve the more general problem of exchanging information over insecure connections, there are several key exchange protocols as mentioned by other answers.

    In general key exchange algorithms are secure from eavesdroppers, but because they do not authenticate the identity of the users, they are vulnerable to man-in-the-middle attacks.

    From the Wikipedia page on Diffie Hellman:

    In the original description, the Diffie–Hellman exchange by itself does not provide authentication of the communicating parties and is thus vulnerable to a man-in-the-middle attack. A person in the middle may establish two distinct Diffie–Hellman key exchanges, one with Alice and the other with Bob, effectively masquerading as Alice to Bob, and vice versa, allowing the attacker to decrypt (and read or store) then re-encrypt the messages passed between them. A method to authenticate the communicating parties to each other is generally needed to prevent this type of attack. Variants of Diffie-Hellman, such as STS, may be used instead to avoid these types of attacks.

    Even STS is insecure in some cases where an attacker is able to insert their own identity (signing key) in place of either the sender or receiver.

    Identity and Authentication

    This is exactly the problem SSL is designed to solve, by establishing a hierarchy of 'trusted' signing authorities which have in theory verified who owns a domain name, etc, someone connecting to a website can verify that they are indeed communicating with that domain's server, and not with a man-in-the-middle who has placed themselves in between.

    You can create a self-signed certificate which will provide the necessary configuration to encrypt the connection, but will not protect you from man in the middle attacks for the same reason that unauthenticated Diffie-Hellman key exchange will not.

    You can get free SSL certificates valid for 1 year from https://www.startssl.com/ - I use them for my personal sites. They're not quite as 'trusted' whatever that means, since they only do automatic checks on people who apply for one, but it's free. There are also services which cost very little (£10/year from 123-Reg in the UK).

提交回复
热议问题