Home/ Questions/Q 336787
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-12T10:16:30+00:00

I’m starting to write a small web application and have started thinking about securing

  • 0

I’m starting to write a small web application and have started thinking about securing login (only used for administration).

If I could, I’d install a CACert or self-signed SSL certificate, since for now I’ll be the only one logging in, but my host isn’t too accommodating.

Are there any reasonable options for securing the site without SSL? I’ve been thinking about options for authentication:

  1. Implement a salted hash in JavaScript. When the login page is loaded, generate a salt server-side. Send it to the client in the clear and store it in a session variable.

  2. Digest authentication. I just found this idea browsing SO, and it’s probably a lot more reasonable than rolling my own auth.

  3. OpenID. It’s an open standard, no passwords are required (and I can “hijack” my OpenID provider’s SSL to add security to the login process), but I have no idea how OpenID works or how secure it is. (Needs research. For example, can an OpenID authentication be replayed?)

The problem with all of these is that:

  • Sessions can be hijacked
  • Only login is secure, everything else is in the clear

The only option I can think of for securing the app after login is some disgusting JavaScript and PHP sending encrypted blobs of ASCII back and forth. I don’t want to do this.

Is there any encryption (for pageloads and POSTs) that can be implemented in my server-side scripting language of choice without the blessing or involvement of my host, but that would be supported by the browser? Can sessions be secured from hijacking (practically) without SSL?

What would you do in a situation like this?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    You can securely authenticate without needing to implement protection against eavesdropping. For example, you can prevent others from sending requests, even though they can read the contents of your requests. If you need to protect against eavesdropping, I’d recommend just going somewhere where you can use SSL.

    If you just need simple authentication without real security, your provider will probably support HTTP Basic. This (along with a good design which limits capabilities, and backups 😉 is a reasonable interim solution while you worry about other problems.

    For authenticating your identity, OpenID can’t be replayed. Each authentication sequence is signed. However, OpenID by itself only lets you establish your identity with the server. It won’t let you sign or otherwise authenticate a request. OAuth would, but it requires transport encryption for part of the protocol.

    You could sign each request with a shared secret. This would prevent an attacker from submitting or replaying a request, but the requests themselves can still be read by an eavesdropper. See the documentation for Amazon AWS authentication (which includes client libraries) or flickr’s authentication. The basic protocol is:

    • require a timestamp (and probably a nonce) as request parameters
    • normalize, sort, concatenate all request parameters
    • concatenate with URI, host, verb, etc.
    • hash with secret key
    • send hash in header with request
    • server does the same and compares signature
    • 0