[aerogear-dev] Should encrypted store fail to open when passphrase is wrong?

Bruno Oliveira bruno at abstractj.org
Tue Jan 21 07:54:51 EST 2014



--  
abstractj

On January 20, 2014 at 3:00:54 PM, Tadeas Kriz (tkriz at redhat.com) wrote:
>  
> Hey,
>  
> I know we’ve been discussing this before, but with no solution.  
> I myself think, that the store should fail to open when the passphrase  
> is wrong, because that’s where you’d like to have your “try ..  
> catch ..” to handle the problem, not elsewhere, when you want  
> to actually read/write/delete from the store, that’s just not  
> very user friendly.
> 
> If the answer to that is YES, then the next question is, how to decide 
> when the passphrase is right and when it isn’t. Again I’ll write 

Like I mentioned here (https://issues.jboss.org/browse/AGDROID-173), our goal to the very initial release was not to make anything perfect, but lay down the groundwork for encryption. So if you where you read “Experimental”, by that means, not perfect.

Offline authentication didn’t start yet, so that might happen. The API will be user friendly when become stable.

> more ways I’ve got on mind, that’d solve this. Important is, that  
> none of them actually stores the passphrase!
> 
> On each call of ‘open()’:
> 1. do ‘readAll()’ to ensure the passphrase is right. Basically,  
> that’s what user has to do now to find out if the passphrase is right.  
>  
> 2. read the first row and if the read is successful, then the passphrase  
> is right. In this case, we’d have to be 100% sure that there is no  
> way to put data into the store with different key and thus all the  
> rows are encrypted with the same passphrase.

We are aware of it, at the same time we didn’t add support for querying into the database. That’s planned, but not atm. Our focus was data encryption, optimizations will come with the next releases, for this reason a jiras like this exist https://issues.jboss.org/browse/AGSEC-137 

>  
> 3. Save some metadata for each data model, that would be encrypted  
> with the same passphrase and we’d read them and if successful,  
> the passphrase is right. This has two possible implementations.  
>  
> a. The first row in the data model table would be reserved for the  
> metadata, so the verification would work similarly to the option 
> 2.
>  
> b. There would be separate table, in which we’d add a row for each  
> data model table. Again, very similar to a. but without the pain  
> of having different data in the same table. Also, if the implementation  
> of SQLStore will become multi-table (instead of multi-database  
> which is now), there would be only one table for all the metadata.  
>  
> So, what do you think?

Repeating what I said on that Jira, it seems too much. APIs like SQLCipher don’t do that.

>  
> PS: For abstractj, I’ve been trying to find any library that would  
> do the encryption on high-level, as AeroGear does, but couldn’t  
> find any. There are many ways to encrypt SQLite database though  
> they work on different approach of encrypting the whole database  
> file, not just rows themselves.

That’s the reason why we’ve been working on it.

>  
>> Tadeas Kriz
> tkriz at redhat.com
>  
>  
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev  
>  




More information about the aerogear-dev mailing list