Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 19 Jun 2016 14:10:16 -0400
From: Scott Arciszewski <>
Subject: Re: Am I Overlooking any Practical Attacks?

On Sun, Jun 19, 2016 at 2:05 PM, <> wrote:

> I'm building a free software project that, I hope, will one day be the
>> secure alternative to CMS platforms like WordPress, Drupal, Joomla, and
>> so many others.
> there are 3 show-stoppers:
> - HTML, it is intrinsically anti-secure (by design: lets run something
> from somewhere within the context of the parent document without user's
> consent!)
> - CMS, it is a non-entity, posing as a non-solution to a non-problem.
> - "so many others"

Are you literally saying "everything under the umbrella of 'web application
security' is insecure"?​

> * Weak passwords are rejected. Weak means a Zxcvbn score < 3 (this
>> parameter can be configured).
> Let me guess, you do not have any definition of "weak/strong" at all.
> As the list is already sick of this reminder of mine:
> you are not allowed to reason about password strength until you define it.
​That comes across as needlessly hostile.

> The password
>> feedback messages also strongly encourage the use of password managers.
> yes! why bother authenticating humans, if you can authenticate an impostor
> software program.
> * In case your password gets leaked, two-factor authentication
> where is a definition of "leaked"?
> and how do you detect the event? (the event?)

​You're that guy from the Internet, aren't you? From that Dilbert comic.​

​(You're famous!)​

> * Database dumps: We use Argon2i for password hashing (provided by
>> libsodium). Hashes are then encrypted using Halite's symmetric
>> encryption feature. The idea here is if you're using RDS (or otherwise
>> have the database on separate bare metal than the webserver), finding a
>> SQLi doesn't even give an attacker the hashes to begin cracking.
> the same time we are happy to provide the encryption key to all our
> PHP-scripts that read this database.
​Right, I specifically laid out this threat model: Database compromised,
the application isn't. It's a narrow use-case.​

> * Usernames aren't even used in the course of interacting with other
>> users  Your username is strictly used for
>> authentication.
> and what's the point?

​The point is to create a compartmentalization between your public identity
and your access credentials.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <>​

Content of type "text/html" skipped

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.