Bug in v1.14beta (password in cache memori but not PIM)

Topics: Technical Issues
Aug 22, 2015 at 10:38 PM
Edited Aug 22, 2015 at 10:40 PM
Problem in v1.14 Beta.
Using PIM and password cache in memory, if you unmount the encrypted volume and mounting it again, the mounting fail because of not saving PIM in memory along with the password.

To make the mounting after the wait and lack mount, simply (without re-entering your password) put the check on PIN and enter the correct value of the multiplier, and the mount is again carried out correctly.

I understand that VeraCrypt not produce income, but find bugs like this is disheartening ... :)
Aug 22, 2015 at 11:27 PM
Did you see anywhere in the GUI or the documentation that the PIM is cached?

It is clearly written that the password is cached and never the PIM so it is wrong to call this a bug.

Moreover, as you can see in the favorite and the system favorite dialog, there is field to specify the PIM to use, especially because the PIM is never cached.

So basically, you need a feature to cache the PIM? In this case what should we cache? Because you can have one password and several PIM values.

Any proposal? This is a new feature and I'm interested in hearing ideas to implement in an efficient way for most cases.

As of today, you can achieve what you want using favorites.
Aug 23, 2015 at 12:41 PM
Edited Aug 23, 2015 at 3:49 PM
How to write, favorites is recorded PIM, but if you do NOT use the favorites and is enabled the "Cache passwords in driver memory", when I ask the system the mounting of the drive, after the first unmounting, the system will NOT ask me if I want to enter the PIM but attempts to mount the volume with what he has, password, and the default PIM ... only when he can't mount the volume present the GUI requiring a password and can insert PIM.

This is either a bug or a bad implementation, I leave to you the choice between the two definitions.

The only suggestion I can make is that when the "Cache passwords in driver memory" is active is suggested the inclusion of PIM "BEFORE" to start trying to mounting. (And then the PIM might well be kept in temporary cache and revived ....)

Another small mistake venial .... In the password prompt, PIM etc., when you check the demand for PIM, the cursor remains in the field PASSWORD instead of being moved in PIM field... if you are not careful and if it has already entered a long password, finds himself replaced by the PIM ...

Concerning the favorites, I personally consider a reduction of safety finding myself PIM reported to a driver written in clear "Favorite Volumes.xml" and repeated punctually each time ...

The PIM actually increases the entropy of the system, is so much safer keeping in temporary cache in one session that into my favorites forever.

Proposed amendment PIM management

Instead of managing PIM separately (as now), why not handle it along with the passwords?

Defining a field (string) in the password is possible (for you) to lighten the management and ease of use with the temporary cache.

Example password: nkj#cds7hjneDjh3j@PIM#xxx#ksal97@à

The PIM field @PIM#xxx# in the example, it is identifiable and fixed field, provided with markers, currently in effect become part of the password, and can be placed at any point of it.
It will still be highlighted the acceptance by the system GUI. It will then be lightened its management and especially facilitated its handling volume for volume and on temporary cache.