LockFailException

[shewison]

Hi,

I'm intermittently getting the following exception when trying to verify as hash:

LockFailException

Failed to lock 9 bytes into RAM. Under current available value of 2048 bytes (try again, it may work). Failed to securely lock 9 (prevMin=204800, min=204800, prevMax=4294967295, max=4294967295, prevFlags=10, flags=10, prevCur=3515860229377112, cur=3515860229377112) bytes at 0x60A8A2A0. Error: Insufficient quota to complete the requested service.. at Isopoh.Cryptography.SecureArray.SecureArray.Init[T](T[] buf, SecureArrayType type) at Isopoh.Cryptography.Argon2.Argon2.Verify(String encoded, String password, String secret, SecureArrayCall secureArrayCall)

[shewison]

Using V1.0.9 Nuget Package and the default implementation with a lower work factor.

Argon2.Hash("foo", 1); Argon2.Verify(hashString, password)

[shewison]

Oh and I'm using it in an IIS hosted ASP.Net application with multiple worker processes in the application pool.

[mheyman]

The code attempts to lock the sensitive information into RAM such that it will never get swapped to disk. This request can be denied by the operating system. On Windows systems it uses VirtualLock and that can fail. I haven't seen it fail in my real-life use cases but I can make it fail in tests. Perhaps your server you is putting more pressure on the operating system than mine :-)

I thought I got all the calls to lock memory to degrade from SecureArrayType.ZeroedPinnedAndNoSwap to SecureArrayType.ZeroedAndPinned. Apparently I missed some....Working on it...

[mheyman]

Uploaded v1.0.9 to nuget.org. I found 4 locations that wouldn't gracefully degrade to merely pinning the memory. Hopefully this bug fix works for you.

shewison, I'm a little concerned that you ran into this bug when the similar code we run (an IIS ASP.Net application) never ran into the bug. Our server has had at the most 30-50 users a day and I doubt we get more than one or two logins a minute so perhaps we just never exercised the code as much as you. But, it is also possible that you are somehow doing VirtualLock calls elsewhere - either using and holding onto SecureArray instances beyond when you need to or using some other code that makes VirtualLock calls. Locking memory eats system resources and the Argon2 code tries to hold memory locked for as short a time as it can. If you have other code locking memory to the point where you saw this behavior, you may experience degradation in performance across your entire system. But, because I've been playing with this, I have found that sometimes the Windows just doesn't allow a VirtualLock and if you try a second time immediately, it will go through - I never tried coding around that because, like I said, the few places we've used this library has never needed to.

[shewison]

mheyman, thanks looking at this so quickly.

I'm not using VirtualLock elsewhere. We operate at a level of 200+ concurrent users at busier times. We also have a product where its usage is clustered around specific times of the day and affinity with the NLB cluster is set to network. So all users at the same site share the same server within the cluster. So there's a reasonable risk of collision with multiple hashes taking place at once.

The web cluster is virtual and running on a hyper-v host. Not sure how this plays into the problem?

I did see your "try again, it may work" comment in the exception. So that was my initial solution, if it fails, wait 500ms and try again. This has reduced the incident rate within the UX.

My next release is scheduled for later this week. I'll update the Nuget package and report if there has been a change.

[shewison]

mheyman,

I've now published the updated package and have been monitoring the logs for a couple of days.

There has been no new occurrences of the LockFailException.

I'm happy for this issue to be closed. Thanks again for responding so promptly.

[SteeeveAT]

Hi!

I got this error in 1.0.8

Isopoh.Cryptography.SecureArray.LockFailException Failed to lock 9 bytes into RAM. Currently available: 0 bytes. Failed to securely lock 9 (prevMin=204800, min=204800, prevMax=1413132288, max=768888832, prevFlags=10, flags=10, prevCur=640741376, cur=640741376) bytes at 0x13FA25FA900. Error: Insufficient quota to complete the requested service..

and updatet, because of this thread to, to 1.1.2. I also set the memorycost lower than deftault:

Argon2.Hash(password,1,32768);

and got the same error.

Its an Windows MVC WebApplication on an webserver with 4GB of Ram.

Is there a way to prevent this error?

Thanks in advance

Steeeve

[shewison]

Steeeve, you don't have the latest version. I had to upgrade to v1.0.9 but despite the lock exception being resolved I found this library struggled in a high volume web environment and instead changed to BCrypt.

[SteeeveAT]

Shewison, I'm on 1.1.2, which is the newst version on nuget... I the problem persists I also hat to change to an other system - me not like 👎