0

I have a current customer base. I want to give them access to certain details about themselves via a RESTful service (through an app).

I want to give the customers as little hassle as possible in getting started with this, so I'm thinking about generating a UUID for each customer and then letting them access the REST by supplying their UUID as a identification.

For example: http://www.example.org/rest/value/UUID or http://www.example.org/rest/value with the UUID as HTTP basic authentication over TLS.

My worry is security. Keep in mind I am new to some of these concepts. What are my main concerns with using a UUID generated-on-demand as "proof" of being a certain customer?

If my above scenario should be open to someone sniffing out the UUID please also concider if I theoretically was able to hide the UUID during transport.

I am aware UUID is not very human-readable, but input is thought to be through URL/QR/similar.

TragedyStruck
  • 586
  • 8
  • 24

2 Answers2

1

Using a UUID as a fixed identifier for a valid user is risky. UUIDs are generated to be unique, not random. If the attacker has a legitimate UUID, he may try to guess other user's identifiers.

Fixed identifiers can also easily leak. Even if you use HTTPS to hide the identifier on the transport channel, there's still a risk that an user uses copies a link into an email or someone scribbles down an identifier from a screen.

Sending the identifier in an HTTP header is a bit more secure as HTTP headers are not reflected in links or shown on screen. Still, if an identifier leaks, the attacker can easily impersonate the user from which the identifier was stolen.

That is why most authentication systems generate (session-) identifiers or tokens which are valid for a limited time. If it gets stolen, there's a limited window in which it can be used.

You do not mention what platform you're running on or whether the REST service is accessed on the internet or on an intranet. In the latter case, in a Windows Active Directory domain, something like Integrated Windows Authentication may be the least hassle (you use the user's logon session).

Otherwise you should probably look at some JWT based authentication mechanism.

Community
  • 1
  • 1
MvdD
  • 22,082
  • 8
  • 65
  • 93
  • Thank you. You mention that "Sending the identifier in an HTTP header is a bit more secure ... Still, if an identifier leaks, the attacker can easily impersonate the user" -- Does this really differ from your regular user/pass which can also be lost? – TragedyStruck Jun 14 '16 at 07:32
  • No, not really. Although a password can be changed by the user. But using username/password is also not recommended to secure an API as it forces the client to keep the password around in plaintext to send along with each request. – MvdD Jun 14 '16 at 13:47
0

Consider implementing an authentication layer based on OpenID Connect 1.0 specification. The provider of authenticated sessions is external from the application in this case. OpenID specification is extensible, so you can use encryption if you want.

Having UUID generated on demand for each customer does not guarantee security by itself. It is not difficult to sniff out the UUID or other clear-text information from HTTP conversation. Open ID Connect is different in that it defines a way for your application to establish an authenticated session and use unique session identifier to validate each subsequent request.

Hope that summary helps. There is more information about how it works here http://openid.net/connect/faq/

arkadio
  • 1
  • 2
  • OpenID Connect is a redirection based protocol and is not a good fit for REST APIs. It is typically used for web applications. – MvdD Jun 14 '16 at 04:10