Keychain: "security add-internet-password" (cloned entries due to Safari)

Hello community,


I am facing an issue when adding internet passwords to a keychain by script (example script below); despite the fact that new entries are added flawlessly.


#!/bin/bash
LOGINNAME=$1
/usr/bin/security \
-v add-internet-password \
-a "$LOGINNAME" \
-l "www.foo.com ($LOGINNAME)" \
-c "apsr" \
-s "www.foo.com" \
-r "http" \
-j "add-internet-password debugging entry" \
-w "MyPassword" \
-T "/Applications/Utilities/Keychain Access.app" \
-T "/usr/bin/security" \
-T "/Applications/Safari.app" \
-t form \
Internet


When opening the relevant website and selecting the login field, Safari shows the appropriate credentials and process with logging in after choosing it. Perfect at first sight. But under the hood, the previously generated entry gets cloned in the keychain. Furthermore, all further logins fall back on the cloned entry.


The cloned entry has some changed values as shown in the excerpt below.


Initial keychain entry added with "security add-internet-password":

security find-internet-password -l "www.foo.com (XRitter)" -g
keychain: "/Users/xritter/Library/Keychains/login.keychain"
class: "inet"
attributes:
0x00000007 <blob>="www.foo.com (XRitter)"
0x00000008 <blob>=<NULL>
"acct"<blob>="XRitter"
"atyp"<blob>="mrof"
"cdat"<timedate>=0x32303135303932303037313934325A00 "20150920071942Z\000"
"crtr"<uint32>="apsr"
"cusi"<sint32>=<NULL>
"desc"<blob>=<NULL>
"icmt"<blob>="add-internet-password debugging entry"
"invi"<sint32>=<NULL>
"mdat"<timedate>=0x32303135303932303037323035365A00 "20150920072056Z\000"
"nega"<sint32>=<NULL>
"path"<blob>=<NULL>
"port"<uint32>=0x00000000
"prot"<blob>=<NULL>
"ptcl"<uint32>="http"
"scrp"<sint32>=<NULL>
"sdmn"<blob>=<NULL>
"srvr"<blob>="www.foo.com"
"type"<uint32>=<NULL>

Cloned keychain entry after first "automated" login (credentials have been automatically filled by Safari):

security find-internet-password -l "www.foo.com (XRitter)" -g
keychain: "/Users/xritter/Library/Keychains/login.keychain"
class: "inet"
attributes:
0x00000007 <blob>="www.foo.com (XRitter)"
0x00000008 <blob>=<NULL>
"acct"<blob>="XRitter"
"atyp"<blob>="form"
"cdat"<timedate>=0x32303135303932303037323031355A00 "20150920072015Z\000"
"crtr"<uint32>=<NULL>
"cusi"<sint32>=<NULL>
"desc"<blob>="Webformular-Kennwort"
"icmt"<blob>="default"
"invi"<sint32>=<NULL>
"mdat"<timedate>=0x32303135303932303037323031355A00 "20150920072015Z\000"
"nega"<sint32>=<NULL>
"path"<blob>=<NULL>
"port"<uint32>=0x00000000
"prot"<blob>=<NULL>
"ptcl"<uint32>="http"
"scrp"<sint32>=<NULL>
"sdmn"<blob>=<NULL>
"srvr"<blob>="www.foo.com"
"type"<uint32>=<NULL>


Furthermore, I noticed that the field kind in "Keychain Access.app" (GUI) contains different values. The initial keychain entry has "Internetpassword" and the cloned one "Webformular-password". My idea was this might be the reason why Safari makes a copy of the inital entry due to a wrong value for the field "kind (meaning Safari takes the initial entry but makes a copy with the "appropriate" value "Webformular-password"). But no matter which "atyp" value I've tried (as described in keychains developer reference), the inital entry gets cloned after first login with Safari. I've tried also -D "form" as well as -c "form".


I am at my wits' end.


Does anybody know what is causing cloned entries and how to avoid them respectively how should entries be added by "security add-internet-password" in order to not induce Safari to create a cloned entry after the first login?


Thanks in advance for any advice.


Regards,


Ritter

"atyp"<blob>="mrof"
"atyp"<blob>="form"

Well, that’s weird. Note how “mrof” is “form” backwards. It’s almost like

security
is messing up the byte order of the value you pass it via
-t form
.

Share and Enjoy

Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

I got it already and wrote an AppleScript around it (as stated here). But I am still wondering, why does Safari updates the entry in the keychain every time when logging in? Even worse, its overwriting the values in the Commentaries field with the value "default". I found it very usefull to have the email address in the Commentaries field (when creating a new account for a disussion forum where I am requested to provide my contact and verification email for example. In case I've changed the password in the forum and didn't update the keychain, I know at least to which email I have to request the notification for restoring the password). Thus, overwriting it each time with just "default" is complete nonsense.


So, is there a toggle in Safari (com.apple.Safari.plist???) or any other solution to switch this nonsense off?

“Why” questions are hard to answer.

My recommendation is that, if this particular behaviour is causing you grief, file a bug explaining why it’s a problem and what you’d like to see happen instead. That way the folks responsible can consider your feedback as they’re working on the code.

Please post your bug number, just for the record.

Share and Enjoy

Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Ritter, I have found the same thing - I think it is a bug in /usr/bin/security

1) I assume that, if yiou are using security add-internet-password to update an existing record, all the attributes have to match exactly. Otherwise, it creates a new record.

2) Several current entires in my keychains (OS 10.9.5) have 0x00000000 blob entries.

Of course, there seems to be no way to use security add-internet-password ... -w newPW -U to create blobs containing anything but four character types :-(

3) I also tried to write a script to reset passwords. For comparison, here is my Perl script:

my $newPW = 'SuperSecure99';
my $chain = '~/Library/Keychains/Telstra\ ACCOUNT-01.keychain';
###############################################################################
`security unlock-keychain $chain`;
#
# Match lines like: 0x00000007 <blob>="gmt.dir.telstra.com (n123456)"
#
# to get list of passwords to update
#
my @names = split /\n/, `security dump-keychain $chain | grep '007 <blob>="' `;
map s/.*="(.+)"/$1/, @names;
foreach my $name (@names)
{
my $serv = $name; $serv =~ s/ .*/
my @keys = split /\n/,
`security find-internet-password -s $serv $chain`;
my $acct = (grep s/.*"acct"<blob>="(.+)"/$1/, @keys)[0];
my $atyp = (grep s/.*"atyp"<blob>=(\w+)/$1/, @keys)[0];
my $icmt = (grep s/.*"icmt"<blob>="(.+)"/$1/, @keys)[0]; # Comment
my $desc = (grep s/.*"desc"<blob>="(.+)"/$1/, @keys)[0]; # Kind
my $ptcl = (grep s/.*"ptcl"<uint32>="(.+)"/$1/, @keys)[0]; # Where URI
my $path = (grep s/.*"path"<blob>="(.+)"/$1/, @keys)[0]; # Where URI
my $cmd = "security add-internet-password ";
if ( defined $acct ) { $cmd .= "-a $acct " }
if ( defined $desc ) { $cmd .= "-D '$desc' " }
if ( defined $icmt ) { $cmd .= "-j '$icmt' " }
if ( defined $path ) { $cmd .= "-p $path " }
if ( defined $ptcl ) { $cmd .= "-r '$ptcl' " }
$cmd .= "-s $serv ";
if ( defined $atyp )
{
if ( $atyp eq "0x00000000 " ) { $atyp = '0000' }
$cmd .= "-t '$atyp' "
}
$cmd .= "-w $newPW -U $chain";
print "$cmd\n";
`$cmd`;
}

One of the 40plus records fails with security: SecKeychainAddInternetPassword /Users/nigel/Library/Keychains/Telstra ACCOUNT-01.keychain: The specified item already exists in the keychain. It is the only one that does not have a duplicate created!

This sounds similar to a problem I encountered with the Keychain UI. Effectively I have a separate keychain to store my bank information. When I go to my bank website, Safari requests that I unlock the keychain. If I allow this, then Safari copies the keychain item from "bank" to "login", thus eliminating the security benefit.


https://openradar.appspot.com/radar?id=4965515323768832


Same thing?

Keychain: "security add-internet-password" (cloned entries due to Safari)
 
 
Q