Sporadica errSecAuthFailed (-25.293) KeyChain quando si accede con SecKeychainFindGenericPassword?

Question

sto scrivendo un app che memorizza le password sul portachiavi, e poi li ottiene con SecKeychainFindGenericPassword (). questo funziona lima il 90% del tempo, ma ogni tanto un po ', la chiamata a SecKeychainFindGenericPassword () fallirà con errSecAuthFailed (-25.293). quando lo fa, solo cercando di nuovo, o riavviare l'applicazione lo ripara.

Qualcuno ha un'idea che cosa potrebbe causare questo? generale di ricerca di Google su questo punti di errore al portachiavi corruzione o il portachiavi di essere bloccato - nessuno dei quali è il caso qui, dal momento che le chiamate successive riescono ancora una volta ...

Answer 1

Non sono sicuro che questo è stato il problema (non vedo come avrebbe potuto essere), ma di recente ho cambiato il mio codice di passare correttamente il strlen() dei CStrings, piuttosto che la lunghezza dei NSStrings nella chiamata. Tecnicamente questo è più corretto (poiché la lunghezza della stringa potrebbe differire dalla CString, se i caratteri a doppio byte UTF-8 sono coinvolti.

MA, nessuno dei nomi utente / password ho provato con caratteri non-ASCII contenute, così ho don; t vedere come questo problema avrebbe potuto effettivamente interessata gli errori che stavo vedendo. Il mio nuovo codice è il seguente, e non ho visto l'errore con esso:

UInt32 length;
void *data;
const char *account = [[BC_HOST stringByAppendingFormat:@":%@", login] cStringUsingEncoding:NSUTF8StringEncoding];
NSLog(@"Getting password from keychain.");
OSStatus s = SecKeychainFindGenericPassword (nil, 
                     strlen(BC_APPNAME), BC_APPNAME, 
                     strlen(account), account,
                     &length, &data, &keychainItem);
if (s != 0) NSLog(@"Error %d obtaining password from keychain.", s);
if (s == 0)
{
    password = [[NSString alloc] initWithBytes:data length:length encoding:NSUTF8StringEncoding];
}

Answer 2

Questo link suggerisce la passphrase che hai inserito non è corretta. Vedi qui E 'possibile che a volte si sta inviando un oggetto null come una passphrase solo per caso?

In alternativa, si potrebbe provare EMKeychain . Ho una versione più up-to-date su GitHub qui: http://github.com/ctshryock/EMKeychain

Answer 3

Non hai condiviso il codice intorno al vostro problema, quindi mi limiterò a indovinare il vostro problema non è con portachiavi disfunzionale, ma piuttosto qualche errore di codifica.

Ecco un errore comune: Dal momento che le API KeyChain sono 'C', e accettano solo in stile C termina con null buffer di stringa, è solitamente necessario per convertire il vostro CFString / NSString oggetti di C buffer prima di consegnarli alle API .

utilizzare molte cose come:

const char *usernameCStr = [username UTF8String];

Per un NSString, o la sua compagna CFString ...

const char *CFStringGetCStringPtr(CFStringRef theString, CFStringEncoding encoding);        /* May return NULL at any time; be prepared for NULL */

Allontanando il fatto queste API possono restituire NULL. Sia perché il buffer interno del CF / NSString è non contigui, o no nella codifica che hai chiesto, o comunque non-c-compatibili.

Tale problema può comportarsi in runtime esattamente come ciò che si descrive.

In questi casi si dovrebbe prendere il problema e utilizzare API diverso per copiare la stringa CF / NS in un C-buffer:

Boolean CFStringGetCString(CFStringRef theString, char *buffer, CFIndex bufferSize, CFStringEncoding encoding);

o

- (BOOL)getCString:(char *)buffer maxLength:(NSUInteger)maxBufferCount encoding:(NSStringEncoding)encoding; 

Answer 4

ho avuto lo stesso problema e nel mio caso questo si è rivelato essere la causa: Impossibile accedere elemento portachiavi dopo l'aggiornamento SMJobBless

Answer 5

Una possibile ragione per cui questo problema può verificarsi è se l'eseguibile che effettua la chiamata non ha accesso alla voce portachiavi. In Accesso Portachiavi è possibile vedere un elenco delle applicazioni che hanno il permesso di accedere alla voce sotto la scheda Controllo di accesso per l'oggetto in questione.

Se la vostra applicazione è in esecuzione da un percorso diverso, si otterrà questo errore. Ad esempio, ho uno strumento Helper privilegiato che sulla mia macchina dev Io di solito corro attraverso Xcode come root. Il percorso di questo eseguibile è il percorso in cui Xcode crea, che è un percorso in ~ / Library / Developer / Xcode / DerivedData // myexecutable. Quando ho eseguito come un utente, esso viene eseguito da / Library / PrivilegedHelperTools / myexecutable. Quindi, se la password è stato inizialmente creato da una versione del app e cerco di leggerlo con l'altro percorso, vedrò l'errore errSecAuthFailed.

Questa non è la solo ragione. Qualcun altro ha menzionato l'aggiornamento sul posto problema che SMJobBless ha. Che può anche provocare lo stesso codice di errore, ma di sicuro lo vedo per entrambi i motivi -. Anche se a livello di codice risolto l'aggiornamento al posto numero ordinando lo strumento di supporto per spostarsi in una posizione diversa prima di fare l'upgrade