I am trying to come up with a way to implement token-based authentication for a REST API without the need for SSL.

Don't!

Use SSL (well, TLS actually).

nothing that isn't public already is going over the wire

This is obviously not exact:

• the user name is captured; TLS would hide user name (I am not saying it is a serious still, but it is an information which is disclosed);
• a hash based on available information is captured and passwords can now be tried (dictionary attack).

I have only started looking at security therefore pretty much a novice at this stuff so any help/advice would be appreciated!

Use the proper tools. Don't try make your own protocols. If you try to come up with your own security protocols, they will almost always be flawed.

There are many issues with your protocol:

• discloses user name (might not be huge issue, but still)
• discloses password hash: allows off-line attack on password
• the server needs to know all passwords in clear-text (either by storing them in clear-text, or storing them encrypted with symmetric encryption, and storing the encryption key) (well not the user password, but the real user secret authenticator)
• and the worst part: absolutely no protection against an active attacker

I am trying to come up with a way to implement token-based authentication for a REST API without the need for SSL.

Don't!

Use SSL (well, TLS actually).

nothing that isn't public already is going over the wire

This is obviously not exact:

• the user name is captured; TLS would hide user name (I am not saying it is a serious still, but it is an information which is disclosed);
• a hash based on available information is captured and passwords can now be tried (dictionary attack).

I have only started looking at security therefore pretty much a novice at this stuff so any help/advice would be appreciated!

Use the proper tools. Don't try make your own protocols. If you try to come up with your own security protocols, they will almost always be flawed.

There are many issues with your protocol:

• discloses user name (might not be huge issue, but still)
• discloses password hash: allows off-line attack on password
• the server needs to know all passwords in clear-text (either by storing them in clear-text, or storing them encrypted with symmetric encryption, and storing the encryption key) (well not the user password, but the real user secret authenticator)
• and the worst part: absolutely no protection against an active attacker

Replying to your update:

I should have been more clear with regards to the SSL.... it's not that I am trying my best to avoid using SSL, it's more catering for the scenario where it isn't an option.

Why isn't it an option in this scenario?

Also, please target your answers more to the reasons why this approach wouldn't work & if it could be tweaked to work rather than "use SSL".

TLS gives you transport level "security": secrecy and integrity (actually, secrecy is limited, as the size of message is leaked; the secrecy of fixed-size keys is protected).

It can be "tweaked" to work without actually using TLS, if you reimplement most of TLS to get transport security without TLS. The implementation cost would be great, and even if you can get all the details right, your implementation might not perform as well as a carefully optimised TLS implementation.

The important question is why you would not want to use TLS.

I am trying to come up with a way to implement token-based authentication for a REST API without the need for SSL.

Don't!

Use SSL (well, TLS actually).

nothing that isn't public already is going over the wire

This is obviously false:

• the user name is captured; TLS would hide user name
• hash(salt,password) is captured and passwords can now be tried (dictionary attack).

I have only started looking at security therefore pretty much a novice at this stuff so any help/advice would be appreciated!

Use the proper tools. Don't try make your own protocols. If you try to come up with your own security protocols, they will almost always be flawed.

There are many issues with your protocol:

• discloses user name (might not be huge issue, but still)
• discloses password hash: allows off-line attack on password
• the server needs to know all passwords in clear-text (either by storing them in clear-text, or storing them encrypted with symmetric encryption, and storing the encryption key)
• and the worst part: absolutely no protection against an active attacker

I am trying to come up with a way to implement token-based authentication for a REST API without the need for SSL.

Don't!

Use SSL (well, TLS actually).

nothing that isn't public already is going over the wire

This is obviously not exact:

• the user name is captured; TLS would hide user name (I am not saying it is a serious still, but it is an information which is disclosed);
• a hash based on available information is captured and passwords can now be tried (dictionary attack).

I have only started looking at security therefore pretty much a novice at this stuff so any help/advice would be appreciated!

Use the proper tools. Don't try make your own protocols. If you try to come up with your own security protocols, they will almost always be flawed.

There are many issues with your protocol:

• discloses user name (might not be huge issue, but still)
• discloses password hash: allows off-line attack on password
• the server needs to know all passwords in clear-text (either by storing them in clear-text, or storing them encrypted with symmetric encryption, and storing the encryption key) (well not the user password, but the real user secret authenticator)
• and the worst part: absolutely no protection against an active attacker