On 4/12/2014 4:41 AM, Iain Buclaw wrote:
> http://privatekeycheck.com/
>
> :o)
>

Dang, now "password" is no longer secure!

On 4/12/2014 5:04 AM, Paolo Invernizzi wrote:
> On Saturday, 12 April 2014 at 08:45:23 UTC, Nick Sabalausky wrote:
>>
>> I shouldn't have to read a label just to know whether or not my food
>> contains dog shit. Some things are basic and obvious enough to just be
>> *expected*.
>
> You have hit the point: in security you _cant_ expect basic and obvious
> things, as you are starting with a biased mindset, you have to care.
>

Never storing or transmitting password in plain text is not only basic, obvious and to be expected, but it is THE most basic, obvious and to-be-expected principle that exists in computer security.

On 4/12/2014 11:21 AM, Dicebot wrote:
>
> You do realize that, for example, forum.dlang.org does not use https and
> thus passwords are sent in plain text over the internet upon every login
> attempt anyway?

I didn't know that (I normally use the NNTP interface and have only ever used forum.dlang.org sans-login). But, yea, that should be fixed.

On 4/12/2014 7:41 AM, Iain Buclaw wrote:
>
> http://privatekeycheck.com/
>
> :o)
>

LOL! An interesting way to check the security of a sysadmin, really. :)

On Saturday, 12 April 2014 at 21:27:10 UTC, Nick Sabalausky wrote:
> On 4/12/2014 11:21 AM, Dicebot wrote:
>>
>> You do realize that, for example, forum.dlang.org does not use https and
>> thus passwords are sent in plain text over the internet upon every login
>> attempt anyway?
>
> I didn't know that (I normally use the NNTP interface and have only ever used forum.dlang.org sans-login). But, yea, that should be fixed.

How would expect it to work? No secure connection of some sort pretty much equals to plain text passwords, one way or another. I am pretty sure forum.dlang.org account is not expected to be any secure, we don't even reserve those nicknames from being used by non-registered posters. It is just small convenience thing to help track posts read.

On Saturday, 12 April 2014 at 09:06:48 UTC, Manu wrote:
>> Encryption and decryption is only client-side so they only store an
>> encrypted database of your passwords.
>>
>
> I mean, how does it run on all of your devices, and integrate with all of
> your software?

It only really works well for desktop browsers in my experience. I haven't tried the Android app, but from what I understand it's basically an app that acts as a browser since it can't integrate within the system browser, which is quite a lousy solution.

I use LastPass, but honestly it's only so it can automatically sign me in to sites (it can automatically submit the sign-in form unlike the default browser password manager). I rarely bother using it to actually generate a password for me. If I were to somehow lose all the passwords in it, it would be inconvenient to remember which I was using for each site, but certainly recoverable.

On 4/12/2014 8:05 PM, Dicebot wrote:
> On Saturday, 12 April 2014 at 21:27:10 UTC, Nick Sabalausky wrote:
>> On 4/12/2014 11:21 AM, Dicebot wrote:
>>>
>>> You do realize that, for example, forum.dlang.org does not use https and
>>> thus passwords are sent in plain text over the internet upon every login
>>> attempt anyway?
>>
>> I didn't know that (I normally use the NNTP interface and have only
>> ever used forum.dlang.org sans-login). But, yea, that should be fixed.
>
> How would expect it to work? No secure connection of some sort pretty
> much equals to plain text passwords, one way or another. I am pretty
> sure forum.dlang.org account is not expected to be any secure, we don't
> even reserve those nicknames from being used by non-registered posters.
> It is just small convenience thing to help track posts read.

Well, *technically* there's https now, but I agree self-signed is likely to just scare people away. So I'll grant it's not a trivial problem (unless StartSSL really does allow multiple free subdomain certs to the same base domain, which IIRC didn't seem to work for me when I had tried it, but maybe I'm wrong. Granted, I did have trouble recently with StartSSL, but as long as multiple subdomains turns out to be ok, then it's still better then self signed. I'd just recommend using a CSR instead of having them generate the key, to minimize chances of anything going wrong. If anything were to go wrong, worst case scenario is nothing more than dlang.org being forced back to self-signed, which is exactly where were already are right now anyway. So I think it's worth trying unless someone wanted to donate a "dlang SSL cert fund")

On Saturday, 12 April 2014 at 21:18:26 UTC, Nick Sabalausky wrote:
> Never storing or transmitting password in plain text is not only basic, obvious and to be expected, but it is THE most basic, obvious and to-be-expected principle that exists in computer security.

... and it is also the most common way passwords are sent in internet protocols.

* SMTP and HTTP will base64 encode it with their basic auth but that's it

* web sites typically transmit it completely open


There's SSL now that gets more traction, but if you expect a password NOT to be sent in something trivially converted to plain text, wake up an smell the RFC.

On 4/12/2014 10:02 PM, Adam D. Ruppe wrote:
> On Saturday, 12 April 2014 at 21:18:26 UTC, Nick Sabalausky wrote:
>> Never storing or transmitting password in plain text is not only
>> basic, obvious and to be expected, but it is THE most basic, obvious
>> and to-be-expected principle that exists in computer security.
>
> ... and it is also the most common way passwords are sent in internet
> protocols.
>
> * SMTP and HTTP will base64 encode it with their basic auth but that's it
>
> * web sites typically transmit it completely open
>
>
> There's SSL now that gets more traction, but if you expect a password
> NOT to be sent in something trivially converted to plain text, wake up
> an smell the RFC.

Well yea, internet protocols tend to use SSL/TLS *as* the password encryption. I think that's fine and good as long as SSL/TLS is actually used, especially since it means the rest of the data is automatically encrypted too, not just the password. It's also nice because it means the various protocols don't have to reinvent their own counterpart to SSL/TLS and risk doing so poorly. People know plain-text-password protocols require an encrypted tunnel, but a broken poorly-designed protocol-specific password encryption scheme is more easily mistaken as a suitable substitute for SSL/TLS.

On 4/11/2014 8:45 PM, Steven Schveighoffer wrote:
> On Fri, 11 Apr 2014 18:05:26 -0400, Nick Sabalausky
> <SeeWebsiteToContactMe@semitwist.com> wrote:
>
>> On 4/11/2014 12:55 PM, Steven Schveighoffer wrote:
>>> On Fri, 11 Apr 2014 12:42:31 -0400, Walter Bright
>>> <newshound2@digitalmars.com> wrote:
>>>
>>>> On 4/11/2014 5:18 AM, Steven Schveighoffer wrote:
>>>>> If, after the last year of hacking, and the heartbleed bug, people
>>>>> are not using
>>>>> password tracker/generators, you haven't learned anything :)
>>>>
>>>> But those pw managers are a single point of failure. One mistake and
>>>> you've compromised or lost everything.
>>>
>>> What mistake?
>>>
>>
>> Pretty much anything? Letting the wrong person see you type your pass.
>
> Not likely.
>
>> Using it on a system (even your own) that secretly has a keylogger or
>> is compromised in any number of other ways.
>
> This would be a problem with any password scheme.
>
>> Getting bit by an ecryption library vulnerability.
>
> No doubt, that would be a temporary issue.
>
>> Using a master pass that turns out not to be quite good enough.
>
> This can be mitigated with multi-factor or hardware authentication. But
> I'm not that paranoid. My password is pretty good.
>
>> Relying on NSA-backed "encryption".
>
> It's based on open standards for encryption, not NSA-backed. What
> encryption do you trust?
>

You can nitpick arbitrary examples all you want, but it changes nothing: We're both fully aware there are plenty of ways password authentication can go wrong. Whether or the password auth is used to protect other passwords or something else does nothing to change that. It just means when it does go wrong, other accounts are automatically compromised too.

>>> Read about LastPass. Your last-pass vault is encrypted and stored in the
>>> cloud.
>>
>> No, it's stored on a server. On the internet. *cough*
>
> Encrypted.
>

Nevermind, I was diverging off to a separate point with that. Not relevant to this discussion anyway.

>> Due to LastPass's closed-ness, all we can do is blindly trust whatever
>> they claim (yea, companies are great at never lying to users), *and*
>> blindly trust all of their software to not contain exploitable
>> vulnerabilities[*]. Look how great that works out for users of
>> Google/Microsoft/etc.
>
> It's based on open standards, and you just have to trust them to have a
> rock-solid implementation, sure. It all depends on who you are willing
> to trust. I don't have enough time in my life to learn encryption
> theory, audit all their code, to prove it to myself. I choose to trust
> experts. YMMV.
>
>> [*] I guess we could reverse-engineer, but closed-source is a great
>> way to ensure most of the people auditing your code are blackhats. Not
>> what I want from software I'd use to store all my passwords.
>
> It has been audited, but not by the entire community. Again, it all
> depends on who you trust.
>

It does come down to trust, but open security audits are vastly easier to trust than some single cherry-picked behind-closed-doors audit. At the very *least* it's more eyes on the code.