7

I am developing a web page where people can write and comment things (no personal informations required) and I need to put a log in form so users can see all their actions on my web page. My idea is to program a log in form without SSL and also allow people to log in with Facebook if they prefer. The page will load completely only if JavaScript is enabled.

  1. My first problem is making sure that nobody can steal the user credential by acting like a man in the middle. I thought of solving it with a first hashing on client side with JavaScript and then on the server side, if I receive hashed values(in case someone deletes some JavaScript), a second hashing and store those hashed values in the user database. Is it a safe way to implement it? Also, are there any chances that some data get lost? If so how can I know if the received data is not compromised?

  2. Protect from dictionary and brute force attacks. I would solve it by counting the number of failed log in attempts associated to that user account and if it is more than 8-10 in row show a CAPTCHA at each of the next log in and also implement a time delay between successive log in attempts. I think in this way IP changes are not going to be a problem because I am counting the number of failed log ins on the server side (I would set a user variable in PHP).

  3. The Log In form. I implemented it in this way (without the hashing for now):

    <input id="username" name="userName" placeholder="Username" type="text"> <input id="password" name="pass" placeholder="Password" type="password">

    But when the form is sent on the URL I can read the password like: /LogIn.php?userName=user&pass=pass How can I hide the password?

What could be other good advices, to achieve as much security as I can without using SSL?

Improve this question
7
  • Stealing a login is the least they could do. MiTM means they can do just about anything - replace the data sent to your server, replace the data coming from your server... if you leak the Facebook login somehow I imagine people will be very annoyed with you. For your number 3, you're probably sending things as a GET request instead of a POST request (which you're not supposed to do for exactly this reason).
    – Clockwork-Muse
    Nov 29, 2014 at 14:04
  • 20
    davide - why don't you want to use SSL/TLS? This may help us understand what you are looking for, as TLS is exactly what you should be using based on the context of your question so far.
    – Rory Alsop ♦
    Nov 29, 2014 at 15:19
  • 1
    From your answers TLS/SSL is a must. Are there any good and not so much expensive or even better free web-hosting services that offer SSL/TLS?
    – user3535688
    Nov 29, 2014 at 15:22
  • 4
    startssl.org offers basic SSL certificates for free.
    – tlng05
    Nov 29, 2014 at 15:30
  • 7
    You seem to be trying to protect against the response from the user to your server being leaked or modified, but you've done nothing to protect against the data sent from your server to the user being modified. If a malicious person has the option of changing the page (even for one user), it can change the page to send the hashed password to your server, and also send the unhashed password to the attacker's server. It doesn't matter how good your hash function is if the attacker already knows the password.
    – hvd
    Nov 30, 2014 at 10:39

7 Answers 7

Reset to default
49

Why are you refusing to use TLS? It works, it has a good track record (some minor exceptions aside). Refusing to use good tools without a compelling reason does not engender confidence and does not immediately suggest professionalism.

Additionally, do not roll your own authentication system. That is silly, and you will make mistakes. Instead, since you expect your users to have a facebook account, use OAuth2 to consume federated identity and authentication. Even better, outsource this to a federation service who has mastered it and even provides code-snippets (https://oauth.io/ comes to mind).

Don't make your life difficult.

Improve this answer
5
  • 20
    If the OP needs to make a case to his boss about paying for a certificate, he should make it clear that overall, trying to roll their own will cost more than just buying a certificate and setting it up. (That's true in terms of both time and risk.)
    – jpmc26
    Nov 30, 2014 at 20:12
  • @jpmc26 That is very well put
    – DTK
    Nov 30, 2014 at 20:45
  • @jpmc26 So what would you say the cost of implementing and setting up a Web of Trust protocol and have OS buy in support for your system? $1 Trillion?
    – Aron
    Dec 1, 2014 at 16:39
  • 1
    @Aron I think it's sufficient say, "more than the OP's project budget."
    – jpmc26
    Dec 1, 2014 at 20:26
  • Guess it depends on what is meant exactly by "rolling your own". In Ruby on Rails/Phoenix (Elixir) communities it seems to be quite common to build custom authentication solutions based on trustworthy crypto libraries such as BCrypt, instead of using third-party authentication libraries which might be too bloated/restrictive.
    – xji
    May 7, 2018 at 19:31
19

SSL/TLS certificates will be free by Q2 2015. Get the certificate here:

https://letsencrypt.org/

Let's Encrypt will offer domain-validated certificates signed through IdenTrust at no charge.

When this goes live, these questions should be closed, IMHO

Improve this answer
9
  • 10
    This isn't the first service which offers basic TLS certificates for free. There is, for example, StartSSL which offers free certificates for quite a while.
    – Philipp
    Nov 29, 2014 at 19:37
  • 2
    Also, "goes live" is not the same as "is recognized by the vast majority of installed iser-agents"
    – Hagen von Eitzen
    Nov 29, 2014 at 22:13
  • 1
    @HagenvonEitzen This tweet might interest you.
    – user10008
    Nov 30, 2014 at 10:22
  • 1
    @user2284570 Read the tweet user10008 linked above your comment.
    – alexia
    Nov 30, 2014 at 17:47
  • 1
    @tepples : All those free certs authorities are for individuals. If you run a commercial service and/or you need to do serious things like involving cross-domains, then you will have to buy a certificate.
    – user2284570
    Dec 1, 2014 at 1:03
12

What could be other good advices, to achieve as much security as I can without using SSL?

You can use TLS instead of doing anything stupid.

Improve this answer
2
  • -1 TLS is the new version of SSL. People usually mean TLS by “SSL”.
    – kinokijuf
    Dec 1, 2014 at 13:53
  • 1
    +1 @kinokijuf - I'm sure Terry knows this. The point is: use one of the existing technologies rather than try to roll your own.
    – TripeHound
    Dec 1, 2014 at 14:21
10

What you are trying to do is impossible without a secure way of sending your files to the client, such as TLS. Your approaches of hashing the password client-side require the javascript to be securely sent to the client. Otherwise, a MITM could simply serve a script that does not hash the password, but instead send the clear text password directly to them.

The important part is that you need trusted code on the client. With TLS, that trusted code is the browser, which in turn verifies the integrity of your javascript to make it trusted as well. Without relying on that or something equivalent (which I do not know of), you can't make any assumptions on what runs on the client's machine.

Improve this answer
9
  • 1
    And preventing this requires essentially re-inventing TLS.
    – Mark
    Nov 30, 2014 at 23:08
  • 3
    @Mark My point is that it is impossible to re-invent TLS or something similar in the javascript of your web page.
    – Yogu
    Nov 30, 2014 at 23:11
  • @Yogu I would not say impossible, but it would be very costly to do it right, and would almost certainly have years of fixing bugs before it was close to right. Additionally, because it would not have the widespread adoption of SSL/TLS/IPSec, it would not have the oversight to find bugs for him.
    – DTK
    Dec 1, 2014 at 3:28
  • 3
    @DTK: If not impossible, how would you make sure that the code you wrote actually runs on the client's machine, if the transport of the scripts can not be trusted?
    – Yogu
    Dec 1, 2014 at 6:07
  • @Yogu At that point, you have the distribution portion of the digital supply chain question and delivering a solution to the endpoints via a trusted mechanism. Since the TLS implementation comes with the browser, if you trust the channel to receive the browser, you can trust the TLS implementation. I am not saying this is good position to be in. In short, don't reinvent TLS and look for a good way to distribute it.
    – DTK
    Dec 1, 2014 at 7:40
3

The only way to be secure without TLS is a browser plugin, which needs to be downloaded... over TLS. And a browser plugin is a huge usability drawback.

The reason for this is there needs to be some trusted code on the user's computer. This can be either the TLS code in the user's browser, or the plugin code.

Improve this answer
1

The other answers are clear - use SSL

however, to point out what would fail if you implemented it as described:

I thought of solving it with a first hashing on client side with JavaScript and then on the server side, if I receive hashed values(in case someone deletes some JavaScript), a second hashing and store those hashed values in the user database. Is it a safe way to implement it? Also, are there any chances that some data get lost? If so how can I know if the received data is not compromised?

so in this scenario a MITM would receive the hash sent by the client - if this was a log-in or similar, they could copy it, and then send it whenever they wish to login as X. Chance of data getting lost? with a MITM, it's basically guaranteed that some data can be lost - the question is will you be able to detect it? as for how do you know that the data received is not compromised, the typical way would be to sign it.

If you really must not use SSL, you could pull it off securely via WS Security instead, but be warned, this is going to be more complicated than just SSL.

Protect from dictionary and brute force attacks.

Generally they can be defeated like you described, however the times you really need to worry about brute-force attacks are offline attacks - that is when your code isn't running and can't protect the data by limiting login attempt frequency - many rounds of hashing are required to do that

The Log In form. I implemented it in this way (without the hashing for now)

what exactly would the difference be for an attacker if they viewed a hashed URL or a hashed payload of the same data? anyways, if you don't want the data in the URL, use a HTTP POST instead of a HTTP GET

Improve this answer
4
  • Is WS-Security supported by any browser? If it is not already built into the browser, then the security can never be better than the method used to send the code to the browser.
    – kasperd
    Nov 30, 2014 at 14:09
  • @kasperd it needs to be implemented via javascript - while not secure against the client, it does protect against a MITM attack. There is a javscript library to help with this. Like I said however, getting this to work (correctly) will be much more complicated than just implementing SSL.
    – user2813274
    Nov 30, 2014 at 16:24
  • 4
    No, it doesn't protect against mitm attacks. Nothing you implement in javascript can protect against mitm attacks. Either you use SSL to protect against mitm attacks, in which case the protection is provided by SSL and not your javascript code. Or you do not use SSL, in which case your javascript code doesn't protect against mitm attacks either, because the javascript code could be tampered with.
    – kasperd
    Nov 30, 2014 at 18:13
  • 2
    @kasperd point taken - if the javascript code was signed, the browser would need to have the functionality for checking signatures, which is basically just re-creating SSL...
    – user2813274
    Nov 30, 2014 at 18:17
1

There actually IS a "secure" authentication scheme on the web that predates SSL called Digital access authentication, so what the questioner is asking isn't quite impossible. This is FAR less secure than SSL, and is subject to brute forcing the password through offline attacks, as well as using an old, poorly trusted hashing algorithm of MD5.

I'd still give the same advice as everyone else though, and tell you that SSL is by far the better solution than relying on an outdated challenge-response based system that hasn't been updated since 1993.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .