From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: opaque data types Date: Sun, 09 Jun 2013 23:56:43 -0400 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: References: <51AE71DB.8060005@yandex.ru> <87zjv41uer.fsf@lifelogs.com> <878v2oxwhr.fsf@lifelogs.com> <87r4gfa8nw.fsf@uwakimon.sk.tsukuba.ac.jp> <87fvwvwgg5.fsf@lifelogs.com> <87li6maa9r.fsf@uwakimon.sk.tsukuba.ac.jp> <87sj0uqdhm.fsf_-_@lifelogs.com> <87a9n2oxu6@ch.ristopher.com> <87bo7iqad2.fsf@lifelogs.com> <87txlancx8@ch.ristopher.com> <87y5alq58o.fsf@lifelogs.com> <877gi5gdsq@ch.ristopher.com> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1370836621 29061 80.91.229.3 (10 Jun 2013 03:57:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 10 Jun 2013 03:57:01 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 10 05:57:00 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UltE2-0001Nf-OF for ged-emacs-devel@m.gmane.org; Mon, 10 Jun 2013 05:56:58 +0200 Original-Received: from localhost ([::1]:46430 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UltE2-0001P3-F8 for ged-emacs-devel@m.gmane.org; Sun, 09 Jun 2013 23:56:58 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59660) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UltDz-0001Ox-MG for emacs-devel@gnu.org; Sun, 09 Jun 2013 23:56:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UltDy-0007Cd-Hc for emacs-devel@gnu.org; Sun, 09 Jun 2013 23:56:55 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:33896) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UltDy-0007CY-BG for emacs-devel@gnu.org; Sun, 09 Jun 2013 23:56:54 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UltDx-0001Kc-6H for emacs-devel@gnu.org; Mon, 10 Jun 2013 05:56:53 +0200 Original-Received: from 85-220-3-95.dsl.dynamic.simnet.is ([85.220.3.95]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 10 Jun 2013 05:56:53 +0200 Original-Received: from tzz by 85-220-3-95.dsl.dynamic.simnet.is with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 10 Jun 2013 05:56:53 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 53 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 85-220-3-95.dsl.dynamic.simnet.is X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.3.50 (darwin) Cancel-Lock: sha1:j7zxWd4FAWaoPz/5jQN1kaUDZ6M= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:160298 Archived-At: On Sat, 8 Jun 2013 10:19:34 +0100 (BST) Christopher Schmidt wrote: CS> Ted Zlatanov writes: CS> Considering we are talking about a regular userspace application CS> with no distributed components I do not see any advantage at all CS> by encrypting passwords in memory. How does interposing a CS> function to extract passwords from a new inbuild type increase CS> security at all? >> >> By making it less trivial to extract them. CS> That is security through obscurity. I disagree with that statement. Perhaps we're talking about different things. My goal is not to obscure the data but to encrypt it so it's not trivially extracted. >> The opaque type makes it possible to change the implementation if >> better ways are available on a platform, e.g. the Mac OS X keychain or >> the Secrets API or the W32 keychain. The fallback mechanism can at >> least make it a little harder to get someone's passwords. CS> Storing passwords using different backends does not require in-memory CS> encryption or a new opaque type. True. But my experience with auth-source.el (which in fact provides these backends) was that it's very hard to make it even a little bit secure at the Lisp level alone. CS> How is this new type in combination with custom hard back ends superior CS> to what auth-info.el is doing already? It's harder to corrupt, inspect, or intercept the underlying data transactions from Lisp code if they are at the C level. You don't have to depend on external utilities if you call the libraries directly. OTOH you have to worry about the API changing... The data you pass back and forth is not visible to every Lisp function. CS> Who's your attacker anyway? >> >> Do we have to do risk assessments too? CS> I do not understand that question. I am saying I hope I don't have to invent an attacker to justify my proposal. Look at it this way: do you feel Emacs provides good enough security? I don't, based on what I know about Emacs Lisp and the underlying C code. When it's not possible to write 15 lines of Lisp to grab my passwords out of memory, I'll be less worried. Ted