5 Updated with reference to DIGEST-MD5
source | link

EDIT - This is probably based on DIGEST-MD5 or similar - Wikipedia currently claims it's still secure, but there's a "citation needed" in a crucial place. Using MD5 is generally a bad idea.

The intention of the hash step is to protect against accidental leaking of the token/password. By hashing with the time, you're basically deriving a very shortshorter-lived token and sending that instead of the original one, so if the derived token were leaked, the original one would still be safe (assuming the security of MD5, so...).

Over HTTPS, this scheme doesn't really offer much more protection than an OAuth Bearer token. It isn't any worse than an OAuth Bearer token of equivalent length, but the fact they've used this scheme (as well calling their secret token a "public key") makes it reasonable to assume that they're not that hot on security, and that will probably be reflected elsewhere in their business (e.g. securely storing the data you send them).

Are youIf you're sending this over plain HTTP? Even with the MD5 shenanigans it's still essentially, then it is better than just a bearerusing the actual token - but you have other problems, sobecause you would need HTTPS to prevent MITM (because a bearer token doesn't help).

EDIT - This is probably based on DIGEST-MD5 or similar - Wikipedia currently claims it's still secure, but there's a "citation needed" in a crucial place. Using MD5 is generally a bad idea.

The intention of the hash step is to protect against accidental leaking of the token. By hashing with the time, you're basically deriving a very short-lived token and sending that instead of the original one, so if the derived token were leaked, the original one would still be safe (assuming the security of MD5, so...).

Over HTTPS, this scheme doesn't really offer much more protection than an OAuth Bearer token. It isn't any worse than an OAuth Bearer token of equivalent length, but the fact they've used this scheme (as well calling their secret token a "public key") makes it reasonable to assume that they're not that hot on security, and that will probably be reflected elsewhere in their business (e.g. securely storing the data you send them).

Are you sending this over plain HTTP? Even with the MD5 shenanigans it's still essentially just a bearer token, so you would need HTTPS to prevent MITM.

EDIT - This is probably based on DIGEST-MD5 or similar - Wikipedia currently claims it's still secure, but there's a "citation needed" in a crucial place. Using MD5 is generally a bad idea.

The intention of the hash step is to protect against accidental leaking of the token/password. By hashing with the time, you're basically deriving a shorter-lived token and sending that instead of the original one, so if the derived token were leaked, the original one would still be safe (assuming the security of MD5, so...).

Over HTTPS, this scheme doesn't really offer much more protection than an OAuth Bearer token. It isn't any worse than an OAuth Bearer token of equivalent length, but the fact they've used this scheme (as well calling their secret token a "public key") makes it reasonable to assume that they're not that hot on security, and that will probably be reflected elsewhere in their business (e.g. securely storing the data you send them).

If you're sending this over plain HTTP, then it is better than just using the actual token - but you have other problems, because you need HTTPS to prevent MITM (because a bearer token doesn't help).

4 Updated with reference to DIGEST-MD5
source | link

EDIT - This is probably based on DIGEST-MD5 or similar - Wikipedia currently claims it's still secure, but there's a "citation needed" in a crucial place. Using MD5 is generally a bad idea.

The intention of the hash step is to CRAMprotect against accidental leaking of the token. By hashing with the time, you're basically deriving a very short-MD5lived token and sending that instead of the original one, so if the derived token were leaked, the original one would still be safe (assuming the security of MD5, so...).

ThisOver HTTPS, this scheme doesn't really offer anymuch more protection than an OAuth Bearer token. It isn't any worse than an OAuth Bearer token of equivalent length, but the fact they've used this scheme (as well calling their secret token a "public key") makes it reasonable to assume that they're not that hot on security, and that will probably be reflected elsewhere in their business (e.g. securely storing the data you send them).

The intention of the hash step is to protect against accidental leaking of the token. By hashing with the time, you're basically deriving a very short-lived token and sending that instead of the original one, so if the derived token were somehow leaked, the original one would still be safe (or would be, if MD5 is secure!).

The fact that they feel this is necessary is slightly concerning - areAre you sending this over plain HTTP? Even with theirthe MD5 shenanigans it's still essentially just a bearer token, so you would need HTTPS to prevent MITM.

EDIT - This is similar to CRAM-MD5

This scheme doesn't really offer any more protection than an OAuth Bearer token. It isn't any worse than an OAuth Bearer token of equivalent length, but the fact they've used this scheme (as well calling their secret token a "public key") makes it reasonable to assume that they're not that hot on security, and that will probably be reflected elsewhere in their business (e.g. securely storing the data you send them).

The intention of the hash step is to protect against accidental leaking of the token. By hashing with the time, you're basically deriving a very short-lived token and sending that instead of the original one, so if the derived token were somehow leaked, the original one would still be safe (or would be, if MD5 is secure!).

The fact that they feel this is necessary is slightly concerning - are you sending this over plain HTTP? Even with their MD5 shenanigans it's still essentially just a bearer token, so you would need HTTPS to prevent MITM.

EDIT - This is probably based on DIGEST-MD5 or similar - Wikipedia currently claims it's still secure, but there's a "citation needed" in a crucial place. Using MD5 is generally a bad idea.

The intention of the hash step is to protect against accidental leaking of the token. By hashing with the time, you're basically deriving a very short-lived token and sending that instead of the original one, so if the derived token were leaked, the original one would still be safe (assuming the security of MD5, so...).

Over HTTPS, this scheme doesn't really offer much more protection than an OAuth Bearer token. It isn't any worse than an OAuth Bearer token of equivalent length, but the fact they've used this scheme (as well calling their secret token a "public key") makes it reasonable to assume that they're not that hot on security, and that will probably be reflected elsewhere in their business (e.g. securely storing the data you send them).

Are you sending this over plain HTTP? Even with the MD5 shenanigans it's still essentially just a bearer token, so you would need HTTPS to prevent MITM.

3 deleted 256 characters in body
source | link

Even setting asideEDIT the use of MD5, this authentication method does not correspond- This is similar to any standard I'm aware of.CRAM-MD5

This scheme doesn't really offer any more protection than an OAuth Bearer token. It isn't any worse than an OAuth Bearer token of equivalent length, but the fact they've added extra weirdness on topused this scheme (as well calling their secret token a "public key") makes it reasonable to assume that they don't really understandthey're not that hot on security, and that will probably be reflected elsewhere in their business (e.g. securely storing the data you send them).

My guess is that the intentionThe intention of the MD5hash step is to protect against accidental leaking of the token. By hashing with the time, you're basically deriving a very short-lived token and sending that instead of the original one, so if the derived token were somehow leaked, the original one would still be safe (or would be, if MD5 is secure!).

The fact that they thoughtfeel this wasis necessary is also slightly concerning - I mean, the token is being sentare you sending this over HTTPS, right? (Rightplain HTTP? 😟) Even with their MD5 shenanigans it's still essentially just a bearer token, so you would need HTTPS to prevent MITM. And if it is being sent over HTTPS, then who are they afraid of seeing the token?

Even setting aside the use of MD5, this authentication method does not correspond to any standard I'm aware of.

This scheme doesn't really offer any more protection than an OAuth Bearer token. It isn't any worse than an OAuth Bearer token of equivalent length, but the fact they've added extra weirdness on top (as well calling their secret token a "public key") makes it reasonable to assume that they don't really understand security, and that will probably be reflected elsewhere in their business (e.g. securely storing the data you send them).

My guess is that the intention of the MD5 step is to protect against accidental leaking of the token. By hashing with the time, you're basically deriving a very short-lived token and sending that instead of the original one, so if the derived token were somehow leaked, the original one would still be safe (or would be, if MD5 is secure!).

The fact that they thought this was necessary is also slightly concerning - I mean, the token is being sent over HTTPS, right? (Right? 😟) Even with their MD5 shenanigans it's still essentially just a bearer token, so you need HTTPS to prevent MITM. And if it is being sent over HTTPS, then who are they afraid of seeing the token?

EDIT - This is similar to CRAM-MD5

This scheme doesn't really offer any more protection than an OAuth Bearer token. It isn't any worse than an OAuth Bearer token of equivalent length, but the fact they've used this scheme (as well calling their secret token a "public key") makes it reasonable to assume that they're not that hot on security, and that will probably be reflected elsewhere in their business (e.g. securely storing the data you send them).

The intention of the hash step is to protect against accidental leaking of the token. By hashing with the time, you're basically deriving a very short-lived token and sending that instead of the original one, so if the derived token were somehow leaked, the original one would still be safe (or would be, if MD5 is secure!).

The fact that they feel this is necessary is slightly concerning - are you sending this over plain HTTP? Even with their MD5 shenanigans it's still essentially just a bearer token, so you would need HTTPS to prevent MITM.

2 added 113 characters in body
source | link
1
source | link