Merci Bru. Il va falloir que je vois comment je combine ça entre les champs en NSTextField qui doivent être lisibles et éditables et les NSSecureTextField quand ils sont vérouillés...
Normalement, si l'utilisateur rend actif File Vault dans ses préférences, l'intégralité de son répertoire est encrypté en 128 bits AES, donc là pas de problèmes...
Sinon, il n'existe pas à ma connaissance de public framework pour accéder à File Vault, et en effet si on ne veut pas l'activer dans les préférences, il faut faire une petite moulinette d'encryption maison.... :-\
Toutes les données sont dans un seul fichier rempli par les classes NSCoding... ça suffit non ? Quand je l'ouvre, c'est du charabia...
Ah, mais je vois des données en clair aussi... donc ça ne suffit pas. :-(
Y'a des méthodes toutes prêtes ou je fais une méthode-algo d'encodage dans mon programme ?
Si tu veux pas te casser la tête à réinventer un encryptage efficace t'as qu'à confier le stockage de tes données sensibles au key-chain. Pour des mots de passe d'accès à un site c'est du reste la solution recommandée me semble-t-il.
Les Keychain....rien qu'à voir le code d'exemple, ben ça me donne pas envie. Pour un projet de grande ampleur, oui, mais dans ce cas, personnellement, je ferais une petite méthode d'encryptage maison.....j'encoderais d'une certaine manière tout les mots de passes en brouillant bien les pistes, avant de les enregistrer via NSArchiver.... Je trouve que c'est bien suffisant. Quand je codais sur Amiga avant, j'avais fait une petite routine de cryptage maison (tout en asm 68k) assez efficace je me souviens, pour des fichiers Key. Je vais avoir besoin d'une routine de cryptage aussi bientôt, et je pense adapter ma vieille routine sur Cocoa.
Les Keychain....rien qu'à voir le code d'exemple, ben ça me donne pas envie. Pour un projet de grande ampleur, oui, mais dans ce cas, personnellement, je ferais une petite méthode d'encryptage maison.....j'encoderais d'une certaine manière tout les mots de passes en brouillant bien les pistes, avant de les enregistrer via NSArchiver.... Je trouve que c'est bien suffisant. Quand je codais sur Amiga avant, j'avais fait une petite routine de cryptage maison (tout en asm 68k) assez efficace je me souviens, pour des fichiers Key. Je vais avoir besoin d'une routine de cryptage aussi bientôt, et je pense adapter ma vieille routine sur Cocoa.
Ta routine de cryptage m'interresse
Mais sinon il me semble que keyChain est bien plus adapté pour des mots de passe administrateurs pouvant être sensibles. De plus c'est pas très compliqué à implémenter. Il suffit par exemple d'une simple instance d'une petite classe perso utilisant KeyChain.h du SecurityHI framework des CarbonFrameWorks et implémentant par exemple:
C'est un cryptage qui n'a absolument rien de révolutionnaire, et qui n'a rien à voir avec les algorithmes de protection hyper balaise genre 128 bits AES ... Les fichiers sont quasiment inviolables après cryptage, car un paramètre aléatoire est à la source du cryptage. je dis quasiment, car le talon d'achille est qu' "il suffit" de désassembler le programme pour avoir accés aux routines de cryptage/décryptage. Mais une telle pratique est loin d'être à la portée de tout le monde, il faut vraiment être expérimenté et savoir lire un programme désassemblé (bonjour le charabia ), et je trouve que ce cryptage est déjà pas si mal en soit.
dans 1098901075:
Mais sinon il me semble que keyChain est bien plus adapté pour des mots de passe administrateurs pouvant être sensibles. De plus c'est pas très compliqué à implémenter.
Quand on sait c'est jamais compliqué ClicCool. ;D ;D
dans 1098901075:
Il suffit par exemple d'une simple instance d'une petite classe perso utilisant KeyChain.h du SecurityHI framework des CarbonFrameWorks et implémentant par exemple:
Oui de telles méthodes ça serait le pied, avec une méthode dans le même genre pour demander le mot de passe administrateur, et le security.framework paraitrait moins rébarbatif...
dans 1098901075:
Mais peut-être que Bru pourrait nous concocter ça ?
Ah bein moi je ne sais plus où donner de la tête et vers quelles solutions me pencher. J'avais presque fini avec les authorization services excepté quelques soucis...
Je crois que je suis parvenu à faire mon premier FrameWork !
Il est tout simple et permet d'utiliser KeyChain pour stocker-coder des password génériques.
il comprend les méthodes suivantes:
-(id) initWithName:(NSString*)inName; Qui permet d'initialiser une instance de la classe KeyChainAcces
- (void)addPassword:(NSString *)password forAccount:(NSString *)account; Adressée à une instance de KeyChainAcces, cette méthode crée un password
- (NSString *)getPasswordForAccount:(NSString *)account; Adressée à une instance de KeyChainAcces, cette méthode lit un password
- (void)deletePasswordForAccount:(NSString *)account; Adressée à une instance de KeyChainAcces, cette méthode suprime un password
Y a-t-il quelqu'un qui veuille bien tester la chose ?
[EDIT] Ah, il semble que Bru se soit gentilment lancé là dedans pendant que je démenais avec mon FrameWork tout beau Dis Bru stp, tu peux me dire si j'ai bon là ? Bien sur faut que j'ajoute les mots de passe internet et Appleshare mais l'idée et là non ?
C'est juste 2 petits fichiers (un .h et son .m) à ajouter au projet pour bénéficier d'une nouvelle classe KEYCHAINAccess.
Les méthodes :
+ (id)loginKeychain retourne le keychain de la session utilisateur (utilisé par safari, etc...).
+ (id)applicationKeychain retourne un keychain spécialement créé pour l'application. Le keychain se trouve dans /library/application support/nom-du-bundle.
- (BOOL)addGenericPassword:(NSString *)password serviceName:(NSString *)servicename account:(NSString *)account ajoute un password à la rubrique servicename sous-rubrique account.
- (NSString *)passwordForServiceName:(NSString *)servicename account:(NSString *)account récupère un password à la rubrique servicename sous-rubrique account.
- (BOOL)deletePasswordAtServiceName:(NSString *)servicename account:(NSString *)account supprime le password à la rubrique servicename sous-rubrique account.
- (BOOL)modifyAtServiceName:(NSString *)servicename account:(NSString *)account newPassword:(NSString *)password modifie le password à la rubrique servicename sous-rubrique account.
Voilà .
Si vous examinez les sources vous pourrez voir qu'on peu facilement mélanger du C standard, du cocoa et du CoreFoundation dans le même programme !
Marant ça on a pas fait tout à fait pareil De mon coté j'ai utilisé le carbonFramework et stocké les passeword directement dans le trousseau d'accès de l'utilisateur ... ....mais on a nommé tous les 2 notre classe KeyChainAcces (à quelques majuscules près )
Marant ça on a pas fait tout à fait pareil De mon coté j'ai utilisé le carbonFramework et stocké les passeword directement dans le trousseau d'accès de l'utilisateur ...
Moi, j'ai utilisé l'API C directement, car elle reste simple et compréhensible. Et surtout, elle est à peu près bien documenté par Apple.
Oui mais ça me dit pas comment paramétrer le "pulic headers folder path" pour que les headers publics se logent convenablement dans version/A et qu'un Alias se place à la racine du framework. ? ???
Merci Bru, cette histoire de keychain m'a donné des idées, il me reste des trucs à comprendre, mais si tout va pour le mieux ta classe va bien me servir pour faire sauter le talon d'Achille de mon cryptage.
dans 1098911648:
C'est juste 2 petits fichiers (un .h et son .m) à ajouter au projet pour bénéficier d'une nouvelle classe KEYCHAINAccess. Si vous examinez les sources vous pourrez voir qu'on peu facilement mélanger du C standard, du cocoa et du CoreFoundation dans le même programme !
J'ai regardé un peu, mais je regarderais plus en détails pour mieux comprendre le fonctionnement des keychains. Belle leçon de programmation ! Bien joué Bru !
ça y est j'ai trouvé comment placer le header et l'alias c'est tellement bourrin que je m'attendais pas à devoir tapper à la main "KeyChainAcces.framework/Versions/A/Headers" dans le panneau de réglage de target. Dans la mesure ou ce chemin est créé par le compilateur y doit bien y avoir une façon plus élégante de l'écrire ? genre $(INSTALL_HEADERPATH") ou quelque chose comme ça non ? ???
C'est un cryptage qui n'a absolument rien de révolutionnaire, et qui n'a rien à voir avec les algorithmes de protection hyper balaise genre 128 bits AES ... Les fichiers sont quasiment inviolables après cryptage, car un paramètre aléatoire est à la source du cryptage. je dis quasiment, car le talon d'achille est qu' "il suffit" de désassembler le programme pour avoir accés aux routines de cryptage/décryptage. Mais une telle pratique est loin d'être à la portée de tout le monde, il faut vraiment être expérimenté et savoir lire un programme désassemblé (bonjour le charabia ), et je trouve que ce cryptage est déjà pas si mal en soit.
La sécurité par l'obsurité..
Il suffit qu'une seule personne dans le monde désassemble ton code pour que tous tes utilisateurs soient vulnérables..
Franchement je vois pas l'interet de réinventer la roue, surtout quand la roue qui est offerte est de bonne qualité..
OS X inclue OpenSSL en standard.. tous les algo de référence dans des implémentations éprouvées et un suivi des vulnérabilité.. Pourquoi se casser la tête et faire prendre des risques inutiles?
OS X inclue OpenSSL en standard.. tous les algo de référence dans des implémentations éprouvées et un suivi des vulnérabilité.. Pourquoi se casser la tête et faire prendre des risques inutiles?
Et bien nucleus si je n'utilise pas OpenSSL, c'est parce que je n'ai aucune idée de comment m'en servir... Là en utilisant les keychains une routine de cryptage maison devient largement moins vulnérable. Même en désassemblant le programme, ça ne servirait à rien car les données seraient cryptées avec un mot de passe enregistré dans les keychains. Mais si tu m'indiques une bonne doc ou même pourquoi pas un framework pour OpenSSL, je veux bien oublier ma roue.
Réponses
Il va falloir que je vois comment je combine ça entre les champs en NSTextField qui doivent être lisibles et éditables et les NSSecureTextField quand ils sont vérouillés...
Parce que si on peut y accéder, et les modifier sans passer par ton appli.. tu as un gros trou de sécurité..
ça suffit non ? Quand je l'ouvre, c'est du charabia...
Ah, mais je vois des données en clair aussi... donc ça ne suffit pas. :-(
Y'a des méthodes toutes prêtes ou je fais une méthode-algo d'encodage dans mon programme ?
Lien doc apple
Sinon, il n'existe pas à ma connaissance de public framework pour accéder à File Vault, et en effet si on ne veut pas l'activer dans les préférences, il faut faire une petite moulinette d'encryption maison.... :-\
Si tu veux pas te casser la tête à réinventer un encryptage efficace t'as qu'à confier le stockage de tes données sensibles au key-chain.
Pour des mots de passe d'accès à un site c'est du reste la solution recommandée me semble-t-il.
Tu as des exemples de code dans la doc de l'ADC.
Ta routine de cryptage m'interresse
Mais sinon il me semble que keyChain est bien plus adapté pour des mots de passe administrateurs pouvant être sensibles.
De plus c'est pas très compliqué à implémenter.
Il suffit par exemple d'une simple instance d'une petite classe perso utilisant KeyChain.h du SecurityHI framework des CarbonFrameWorks et implémentant par exemple:
- (void)addPassword:(NSString *)password forName:(NSString *)name account:(NSString *)account;
- (NSString *)getPasswordForName:(NSString *)name account:(NSString *)account;
- (void)deletePasswordForName:(NSString *)name account:(NSString *)account;
Mais peut-être que Bru pourrait nous concocter ça ?
C'est un cryptage qui n'a absolument rien de révolutionnaire, et qui n'a rien à voir avec les algorithmes de protection hyper balaise genre 128 bits AES
Quand on sait c'est jamais compliqué ClicCool. ;D ;D
Oui de telles méthodes ça serait le pied, avec une méthode dans le même genre pour demander le mot de passe administrateur, et le security.framework paraitrait moins rébarbatif...
Ouai vas-y Bru ! On est tous avec toi !Â
Vous me pousser au keychain alors...
D'ailleurs, je prépare un tut sur son utilisation.
En attendant, ce soir je vais vous poster une petite classe permettant d'ajouter et de récupérer des passes dans votre keychain perso.
Patience...
.
Il est tout simple et permet d'utiliser KeyChain pour stocker-coder des password génériques.
il comprend les méthodes suivantes:
-(id) initWithName:(NSString*)inName;
Qui permet d'initialiser une instance de la classe KeyChainAcces
- (void)addPassword:(NSString *)password forAccount:(NSString *)account;
Adressée à une instance de KeyChainAcces, cette méthode crée un password
- (NSString *)getPasswordForAccount:(NSString *)account;
Adressée à une instance de KeyChainAcces, cette méthode lit un password
- (void)deletePasswordForAccount:(NSString *)account;
Adressée à une instance de KeyChainAcces, cette méthode suprime un password
Y a-t-il quelqu'un qui veuille bien tester la chose ?
[EDIT] Ah, il semble que Bru se soit gentilment lancé là dedans pendant que je démenais avec mon FrameWork tout beau
Dis Bru stp, tu peux me dire si j'ai bon là ?
Bien sur faut que j'ajoute les mots de passe internet et Appleshare mais l'idée et là non ?
[Fichier joint supprimé par l'administrateur]
Pour y'a pas mon header ? ???
Je buche encore un peu sur mon "target Setting" ...
C'est juste 2 petits fichiers (un .h et son .m) à ajouter au projet pour bénéficier d'une nouvelle classe KEYCHAINAccess.
Les méthodes :
+ (id)loginKeychain
retourne le keychain de la session utilisateur (utilisé par safari, etc...).
+ (id)applicationKeychain
retourne un keychain spécialement créé pour l'application. Le keychain se trouve dans /library/application support/nom-du-bundle.
- (BOOL)addGenericPassword:(NSString *)password serviceName:(NSString *)servicename account:(NSString *)account
ajoute un password à la rubrique servicename sous-rubrique account.
- (NSString *)passwordForServiceName:(NSString *)servicename account:(NSString *)account
récupère un password à la rubrique servicename sous-rubrique account.
- (BOOL)deletePasswordAtServiceName:(NSString *)servicename account:(NSString *)account
supprime le password à la rubrique servicename sous-rubrique account.
- (BOOL)modifyAtServiceName:(NSString *)servicename account:(NSString *)account newPassword:(NSString *)password
modifie le password à la rubrique servicename sous-rubrique account.
Voilà .
Si vous examinez les sources vous pourrez voir qu'on peu facilement mélanger du C standard, du cocoa et du CoreFoundation dans le même programme !
Bonne prog.
.
[Fichier joint supprimé par l'administrateur]
- le fichier keychain créé par +(id)applicationKeychain se nomme "passwords.keychain".
- Ce fichier se trouve dans "/Users/~/Library/Application support/non-du-bundle/".
- Par défaut dans un projet XCode, le nomp du bundle est "com.apple.myCocoaApp".
.
le keychain généré par l'application via +(id)applicationKeychain est accessible dans l'utilitaire "trousseau" dans le dossier applications.
.
De mon coté j'ai utilisé le carbonFramework et stocké les passeword directement dans le trousseau d'accès de l'utilisateur ...
....mais on a nommé tous les 2 notre classe KeyChainAcces (à quelques majuscules près
ah bon !, alors sur ce point encore on a fait pareil.
Mais j'ai toujours pas trouvé pourquoi dans mon framework Xcode ne place pas un alias vers le header alors que je l'ai déclaré publique ?
[tt]
   KEYCHAINAcces *kc;
   NSString *passe;
   kc=[KEYCHAINAccess applicationKeychain];
   // enregistrer un passe
   [kc addGenericPassword:@password serviceName:@liste_passe account:@passe1];
   // récupérer un passe
   passe=[kc passwordForServiceName:@liste_passe account:@passe1];
   NSLog(@le passe est %@", passe);
   // modifier un passe
   [kc modifyAtServiceName:@liste_passe account:@passe1 newPassword:@nouveaupasse];
   // supprimer un passe
   [kc deletePasswordAtServiceName:@liste_passe account:@passe1];
[/tt]
.
Moi, j'ai utilisé l'API C directement, car elle reste simple et compréhensible. Et surtout, elle est à peu près bien documenté par Apple.
.
Merci Bru, cette histoire de keychain m'a donné des idées, il me reste des trucs à comprendre, mais si tout va pour le mieux ta classe va bien me servir pour faire sauter le talon d'Achille de mon cryptage.
J'ai regardé un peu, mais je regarderais plus en détails pour mieux comprendre le fonctionnement des keychains. Belle leçon de programmation ! Bien joué Bru !
Dans la mesure ou ce chemin est créé par le compilateur y doit bien y avoir une façon plus élégante de l'écrire ? genre $(INSTALL_HEADERPATH") ou quelque chose comme ça non ? ???
Bon en attendant ça marche
Au lit maintenant
Faudra un peu me prendre par la main...
Tu peux compter sur nous, bien sûr !
De toute façon, je vais faire un tut dessus, histoire d'enrichir notre collection...
.
La sécurité par l'obsurité..
Il suffit qu'une seule personne dans le monde désassemble ton code pour que tous tes utilisateurs soient vulnérables..
Franchement je vois pas l'interet de réinventer la roue, surtout quand la roue qui est offerte est de bonne qualité..
OS X inclue OpenSSL en standard.. tous les algo de référence dans des implémentations éprouvées et un suivi des vulnérabilité.. Pourquoi se casser la tête et faire prendre des risques inutiles?
Et bien nucleus si je n'utilise pas OpenSSL, c'est parce que je n'ai aucune idée de comment m'en servir... Là en utilisant les keychains une routine de cryptage maison devient largement moins vulnérable. Même en désassemblant le programme, ça ne servirait à rien car les données seraient cryptées avec un mot de passe enregistré dans les keychains. Mais si tu m'indiques une bonne doc ou même pourquoi pas un framework pour OpenSSL, je veux bien oublier ma roue.