Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Add Custom HTTP Basic Auth Entries to iCloud Keychain

DZone's Guide to

Add Custom HTTP Basic Auth Entries to iCloud Keychain

We take a look at how to make life easier when it comes to keeping your credentials secure but still accessible on various iOS devices. Read on for the details.

· Security Zone ·
Free Resource

Discover how to provide active runtime protection for your web applications from known and unknown vulnerabilities including Remote Code Execution Attacks.

While automatic filling of HTTP basic auth credentials works fine on the Mac, I have had significant trouble getting it to work on iOS devices. This is especially unfortunate, because while on the road I sometimes need to have a look at monitoring systems that have HTTP basic authentication enabled and that use long complex passwords. Should be easy with iCloud keychain, right? Yeah...

Opening the respective site in iOS Safari pops up the basic auth credentials dialog. It also shows the little key icon in the keyboard toolbar which gives access to iCloud keychain entries. However, while on the Mac the username and password fields are correctly populated, on iOS you cannot even see the respective entry.

Turns out, and I assume this is a bug in iOS Safari, the type of keychain entries shown is limited to "Web form password." Safari on the Mac stores the entry as "Internet Password" though, as can be seen in the Keychain Access application on the Mac:

Knowing that, we just need to change the type or create a new entry in the iCloud keychain. That should be easy, right? Well...

Turns out, there is no way to specify the type when adding a new entry via the Keychain Access app. So that does not help. On to changing the existing "Internet Password" item then... But also no luck there. While you seem to be able to change the type in Keychain Access by just changing the value of the "Kind" field, this apparently has no impact on the actual type in the database underneath.

There is a (kludgy) way, though, that works: Edit any other "Web form password" that was created by Safari (when you allow it to save a password for a website with a login form) and then edit the URL, username, and password fields in Keychain Access. What caught me at first and almost made me think it didn't work was that you need to hit Cmd-S to save the changes made to the entry. For some reason using the "Save Changes" button in the window did not actually do that.

Getting a new web form entry is also quite easy, without having to actually use a real website. I just saved this minimalistic HTML form to a local file to my local drive as "dummy-password.html" and then served it up to Safari with the Python SimpleHTTPServer:

<html>
  <body>
    <form action="http://localhost:8080/doesntmatter" method="post">
    <label for="username"><b>Username</b></label>
    <input name="username" placeholder="Enter Username" required="" type="text" />
    <label for="password"><b>Password</b></label>
    <input name="password" placeholder="Enter Password" required="" type="password" />
    <button type="submit">Login</button>
  </form>
</body>
</html>

Then in the same directory where the file is saved start the HTTP server via Terminal:

$ python -m SimpleHTTPServer 8080

Now, in Safari go to http://localhost:8080/dummy-password.html. It will show you simple password form. Enter the credentials you want to save in the keychain and hit the Login button. Even though you will get an error message displayed because there is nothing the data can actually be sent to, Safari will nevertheless offer to save what you just entered:


Keychain Access will show the new entry as "localhost." Double-click and edit the entry. Remember to save with Cmd-S when done. Notice that it seems to not reliably save multiple changed fields at once. I noticed that while the domain part was correctly saved, the changed port was not. So I went in again and changed the port, which finally made it stick.


After a few seconds they entry showed up on my iPhone, too. Eureka!

One final tidbit: The ordering in the list of credentials shown on the iPhone is a little strange. At first, I could not find my new entry (which was a little longer than the one shown in the screenshot above). Turns out, Safari orders them by the second level domain, not by the subdomains. It makes sense insofar as that otherwise most sites would be sorted under "w" (www being a very common subdomain). But when you have something like "monitoring.staging.test-domain.com" you will find your entry sorted under "test-domain.com", not "monitoring."

Find out how Waratek’s award-winning application security platform can improve the security of your new and legacy applications and platforms with no false positives, code changes or slowing your application.

Topics:
security ,http ,authentication ,ios security ,password security

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}