41

I'm switching over from a heroku addon to a direct redis cloud account and am a bit puzzled on how to generate the redis url with the auth info.

The old heroku add-on url was in the format of redis://rediscloud:mypassword@redis...

However in the dashboard and documentation I don't see any mention of a username to go along with the password. Do I still set rediscloud as the username in my new account and connection string. Does it even matter what I set as the username there?

MonkeyBonkey
  • 46,433
  • 78
  • 254
  • 460

4 Answers4

45

I use golang (https://github.com/garyburd/redigo) and connect to aliyun cloud Redis (link: https://www.aliyun.com/product/kvstore?spm=5176.8006303.267657.7.cW2xH)

By the connect string:

redis://arbitrary_usrname:password@ipaddress:6379/0

when 0 is the database index and success

Uwe Keim
  • 39,551
  • 56
  • 175
  • 291
billschen
  • 699
  • 6
  • 11
  • 54
    Passing an empty username seems to work fine, as in `redis://:password@...`! – damd Dec 14 '18 at 09:23
  • 6
    The username is no longer 'arbitrary' since ACL support was released in Redis 6. Having an arbitrary username (like `rediscloud`) in the URL can now break AUTH depending on the client's authentication logic. – Allison Oct 18 '21 at 15:16
26

At the moment (up to and including v4), Redis doesn't support users and only provides authentication against a global password. In order to be compliant with the URI RFC (https://www.rfc-editor.org/rfc/rfc3986) and based on the provisional RFC for Redis URIs (https://www.iana.org/assignments/uri-schemes/prov/redis), you can pass anything as a username, including the empty string, and it will be okay (i.e. ignored).

P.S. thanks for bringing up this obscurity in our docs, I'll see that it is amended.

Community
  • 1
  • 1
Itamar Haber
  • 47,336
  • 7
  • 91
  • 117
11
  • Version 6+ now supports users: https://redis.io/topics/acl
  • If you aren't using an Access Control List (ACL) for your instance (meaning you auth as the default user) or are using an older version of Redis, you should omit the username from your Redis URL (e.g., redis://rediscloud:mypassword@...redis://:mypassword@...)
  • If you include a username like rediscloud in the URL and your instance doesn't have that user configured in your ACL, you will likely run into auth issues for WRONGPASSWORD errors as more Redis client libraries implement ACL support.
Allison
  • 1,925
  • 1
  • 18
  • 25
  • Your last observation reveals what in my opinion is a rather poor design choice from security standpoint... `redis-server` informs a potential adversary that no password has been set... (the error message displayed by the python `redis` client is: `'ERROR': 'Client sent AUTH, but no password is set'`) – mirekphd Oct 31 '22 at 13:08
  • There are many redis clients libraries and they likely all handle things in some shade of 'similar', but that sounds like it would be for an entirely different issue (a redis user w/ no password set). At the time I wrote this I had just read through the redis-rb source code and notified their maintainers of the root cause of a bug in v4.5.0 where the release had changed behavior from falling back to attempting AUTH as the default user (with just a password), which broke many people's ability to connect to their redis instance if they had configured it via heroku or were using older redis. – Allison Nov 02 '22 at 04:24
  • @mirekphd Yeah, your issue is totally different... that's a warning to the developer that they're attempting to auth with a blank password: https://github.com/redis/redis-py/blob/9fe836698ca5930e39633b86839b6c1bae07237e/redis/connection.py#L71-L78 ... the issue I'm referring to is the client attempting to AUTH as the wrong user with a valid password. – Allison Nov 02 '22 at 04:27
  • Possibly it is off-topic, but stating that the password was incorrect would be slightly more secure than just telling the adversary what the password was:) – mirekphd Nov 06 '22 at 19:37
  • IMO it's the opposite: WRONGPASSWORD would be confusing and make a developer *significantly more likely to dismiss the error* if the AUTH succeeds, thus never setting a password + rendering badly configured instances MORE vulnerable. A developer would need to ignore the no password message for an inexcusable period of time for the instance to both be filled with anything worth compromising and be discovered by a malicious actor... it would require a significantly greater pattern of developer negligence to ignore a 'no password' error than it would to ignore a mysterious wrong password error. – Allison Nov 07 '22 at 19:45
7

This format worked for me when SSL is required:

rediss://:password=@redis-server-url:6380/0?ssl_cert_reqs=CERT_REQUIRED'

An example is below:

CELERY_BROKER_URL='rediss://:ahhrk5958rndfngrkqoq=@my-app.redis.cache.windows.net:6380/0?ssl_cert_reqs=CERT_REQUIRED'
CELERY_RESULT_BACKEND='rediss://:ahhrk5958rndfngrkqoq=@my-app.redis.cache.windows.net:6380/1?ssl_cert_reqs=CERT_REQUIRED'
Promise Preston
  • 24,334
  • 12
  • 145
  • 143