New answers tagged

0

Lots of good answers already in this thread, but to directly address the question: From the perspective of an evildoer who wants to access this resource, are these approaches equivalent? If not, what makes them different? Let me establish a definition. "Authentication" is the providing of credentials to prove a claim of identity. Access control is ...


2

A secret URL is just as secure as a secret password. However, passwords are easier to keep secret than URLs, because everyone and their programs knows that passwords must remain secret. For instance, your browser will not show a password on screen, only store passwords with your permission, and offer means to protect that password storage (such as ...


0

No. An article about an attack came out today that allows URLs to be exposed over HTTPS, so if that is your only means of authentication, it is currently broken.


4

Pretty much all authentication schemes boil down to proving that you know a secret. You authenticate yourself to some service by proving that you know a secret password, or a secret URL or,... Some more advanced protocols (e.g., OAUTH, Kerberos, ...) enable you to prove that you know the secret without actually transmitting the secret. This is important ...


49

A private URL is somewhat weaker than authentication with credentials, even if the bit size of the URL is the same as the credentials. The reason is the URL may more easily "leak". It is cached in the browser, logged on the server and so on. If you have outbound links, the private URL may show up in the referrer header on other sites. If it leaks (by ...


18

As Robert Harvey has pointed out, the only way to securely use a random/private URL is to generate the page dynamically and submit the URL to the user in a way such that the user can be considered authenticated. This could be email, SMS, etc. A randomly generated/private URL should have a few properties: It should expire after a reasonable amount of time ...


1

As Morons mentioned in their answer, it is very difficult to verify the entity at the other end of the connection. The simplest way to provide some level of authenticity is to have the server check some secret that that only the real entity would know. For a user that might be a username and password. For a piece of software where there is no user you ...


-1

You can use diffie hellman algorithm (https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange) to share a secret over a public chanel. In your case I think you should also have a central server that keeps track of who owns which device. Each device should have a unique identifier and when a user purchases a device there should be a registration ...


10

It's unsafe because it exposes your password a number of different ways. Any user can see it in the output of programs like top and ps aux -www. They don't need to be root for to see your processes. It gets logged into your shell history, so if you do something foolish like chmod 777 ~, anybody and everybody can cat ~user/.history and view the password. ...


0

In token based auth systems, a common pattern is to differentiate between short lived tokens and long lived tokens. Short lived tokens are used for all API calls and expire quickly. Long lived tokens are only used for retrieving short lived tokens, and their exposure to other environments is minimized. When a user first logs in, they get a long lived token ...


1

In the end, if I didn't misunderstand you, you've got the following situation: Android device has a clock set to a potentially random/wrong time. There's no network connection other when deploying them in their dock (probably during the night or in the morning). As such I assume the only unknown value is the time offset between the local device's clock ...



Top 50 recent answers are included