Abstracting the storage of the nonces?

[h4cc]

How about abstracting the storage for a nonces? This way other storages can be implemented, even by the user fitting for their needs.

[r8or0pz]

Yea, currently they are stored on File System which is the lag. Abstracting it would be great improvement to let them go in-memory store, for example.

[h4cc]

How about using this beauty? https://github.com/KnpLabs/Gaufrette

There would be a LocalAdapter , ApcAdapter, InMemoryAdapter and even DoctrineDBAL.

[djoos]

I'm definitely in favor of implementing storage abstraction into the bundle!

Gaufrette is an interesting project (we're making use of it), even though it needs to be said it is still under heavy development; so not sure whether everyone making use of the WSSE Authentication bundle would want to throw Gaufrette into the mix...

Please do let me know your thoughts!

[r8or0pz]

Just wonder why there's no HMAC Authentication Bundle for Symfony2...

[h4cc]

I think using a Filesystem Abstraction might be overkill.

In the end a simple Key => Value Storage Interface will do the trick.

interface NonceContainer {
  public function getNonce($nonce);
  public function setNonce($nonce, $content);
}

[djoos]

Hi guys,

what about using doctrine/common cache? (http://docs.doctrine-project.org/en/2.0.x/reference/caching.html) It provides a very simple interface to implement ApcCache, ArrayCache, FilesystemCache, MemcacheCache, MemcachedCache, PhpFileCache, RedisCache,...

Let me know what you think!

[h4cc]

:+1: Using doctrine/cache ~1.0 seems to be a quite good decision.

Using a service id, that can be defined via bundle config seems the most reasonable to me. Default service would be a filecache like it is now.

[djoos]

FYI: I've finally had the time this evening to start implementing nonce storage abstraction. I've got a WIP-version up and running.

I'll keep you updated!

Kind regards, David

[fberci]

I see that nonce storage has been implemented using Doctrine Cache. I think that this is a dangerous decision. The nonce is supposed to prevent replay attacks and what it needs to be able to do that is a durable storage solution. If the storage solution doesn't fulfill the requirement of durability (i.e. making sure that data cannot be lost), it cannot guarantee with a 100% certainty that a nonce can't be reused. However, a cache system's main goal is performance. Furthermore, usually it is employed in conjunction with a durable storage solution in order to increase performance by giving up on durability.

So, to sum up, in theory a cache system is more or less the opposite of what's needed here.

I understand though that replay attacks are very rare (for most people), and even with a solution that provides durability only 95% of the time (the percentage is just an example) an attack would be hard to execute. Also, with the necessary knowledge, Doctrine Cache could probably be configured to provide durability too. But still, from a security standpoint, using a cache for a task like this is not a good idea.

What I would like to see as far as nonce storage abstraction goes is the ability to store nonces in a relational database. That would be good, because relational databases are mostly ACID, so not only do they provide durability, but they also guarantee that if you have two servers, they will see the same data.

BTW, I'm an active user of the bundle, and grateful for all your work, I just thought I'd offer my viewpoint.

[h4cc]

@fberci I understand your concerns, but i dont think that these will result in a real problem.

The Doctrine/Cache was chosen to have a common Interface for storage of the nonces. Before that, only saving to a local directory was usable which also had some downsides, like my issue #24 .

The current implementation used Doctrine\Common\Cache\PhpFileCache, which will store the nonces in a local directory. So practically, nothing has changed except some fixed bugs and more Flexibility.

If you want a different type of storage, you can select one of the available adapters: https://github.com/doctrine/cache/tree/master/lib/Doctrine/Common/Cache or write one yourself, if there is a need for ACID Storage.

The naming "Cache" might be wrong in the context it is used here, but the functionality fits the requirements perfectly.

[fberci]

@h4cc First of all, let me say that this will probably not be an issue for most of the users of this bundle, including myself.

What was changed in the new implementation is that the nonces are now stored by default in the cache directory that is cleared from time to time. This way, "current" nonces (that were used less time ago than the lifetime) can also be deleted. This is a security issue, even though most users probably don't care about it.

You make a good point though saying that I have the option of creating a new storage provider, I guess I just want to emphasize the fact that the naming can be misleading and it would be dangerous to start using some of the existing Doctrine Cache providers (the Memcache one for example). Maybe this could be explained in the documentation.

[h4cc]

@fberci Oh, yes - that is a good catch!

This part of the Bundle should be configureable, or mentioned in the readme. https://github.com/escapestudios/EscapeWSSEAuthenticationBundle/blob/master/Resources/config/services.yml#L20 Also the purpose of the nonces needs some clearance in the docs.

By the way, there are some systems with persistent storage accessable with memcached's protocol: http://en.wikipedia.org/wiki/Memcached :)

[djoos]

Hi guys,

thanks for this thread! I agree that "cache" might be a misleading name for what the Doctrine Common cache is used for by the bundle... By default exactly the PhpFileCache is used to create nonces in the same location prior to the changes (in the %kernel.cache_dir), but allowing for more flexibility than before - as discussed above.

Please don't hesitate to create a PR with additional documentation so I can get that merged in. The documentation could do with more TLC in general to be honest...

Thanks in advance for your feedback - have a great weekend!

Kind regards, David