When C++ and Java (the current industry standards) have adopted the last feature of Lisp then the world will realize that it actually wanted Lisp after all :-)
Lisps != lisp programs. Lisp lets programmers treat their code as data to be edited at runtime. Which is a different model than say Java.
The advantage is individual programmers can be more productive, but it becomes really hard to share code as every program evolves into it's own language.
A normal e-mail client doesn't suffer from this issue. Only if the user is hosting their e-mail traffic inside the US. You may think that's true for everyone, but that is your own bubble or tunnel vision. Say, you are working at the EP (European Parlement). You use Mozilla Thunderbird for your e-mail. Some of the e-mail you receive is internal from your party. The SMTP and IMAP server is hosted in your European country. Then, one day you switch from Mozilla Thunderbird to Nylas N1. Suddenly, your e-mail is not hosted in the EU anymore, and the US government can use a NSL to read your private data. You may not give a rat about this (and if you're from US I can fully understand), that's your discretion. Others do, and their viewpoint is not 'absurd'.
> Which supported service is not already running in the USA and subject to NSLs?
Any SMTP and IMAP server not hosted in the USA. You know, you don't have to use Gmail.
(Nylas Mail doesn't suffer from this problem. Only a few features still require Nylas servers.)
This comment made me smile. Mostly because it threw a new a new light on what I was already thinking; self-host (love how my phone assume I mean "self-hatred", not "self-host", btw) the whole stack, and avoid new security issues that come with forced hosting in hostile jurisdictions.
But take a new daemon that talks a cross product of tls/ssl and three(?) protocols, is supposed to parse random emails, expose it to the Internet - and claim "no new security issues"?
It's reasonable to point out this, true. But in the scope of the parent discussion, it was about NSLs from hosting in countries with compromised providers. If you are running your own mail server, you have mostly the same security issues you need to zealously guard against, wherever you put it.
>We suggest that you include five words of 5-10 letters in size, chosen at random, with spaces, special characters, and/or numbers embedded into words.
>You need to be able to recall the passphrase that was used to encrypt the file.
Why bother writing security guidelines which are impossible for a human to follow?
edit: Try recalling any passphrases generated by the command below, and that's before the random sprinkling of punctuation.
I've been thinking about this for a while, and the early conclusion I've come to, is that 64bits of provable random entropy in a password that's also memorable is a very high bar to clear.
Imagine this, you take four word types/groups, say, substantive, verb, adverb, preposition/place.
You list 128 of each - all with identified uniqly by the first two letters. You let a machine pick a word from each column at random. The phrase is your mnemonic key, the password (to type in) is the first two letters of each word, concatenated.
If you want to appease password strength checks, capitalise the first letter, and end the input with a period.
So: "girl runs happily up", becomes "giruhaup" (or, with equivalent entropy, but satisfying "at least three symbol groups": "Giruhaup.").
Now, that's then 4 picks out of 128 words, or an encoding of 4 times 7 bits (2^7=128) - 28 bits. You'd need three such passwords concatenated to break past 64 bits of entropy. And you'd have to type in 24 letters. That's pretty hard to type in blind without a typo.
You might be able to use lists of 256 words - but it'd make it a bit more difficult to make the wordlists (because words should be identified by the first two characters) - and you'd still need two "phrases" and type in 16 characters.
Adding random numbers, symbols or capitalization is probably not worth the challenge they add in remembering where they go, for the single/few bits of entropy they add.
And I'm still not convinced 16 characters is short enough to be usable for "most people".
Rather than rolling your own password system, I would recommend diceware.com for strong passwords (including master passwords) that you can memorize (I am bad at memorization, and have memorized 129 bit passwords this way, and 64 bit passwords are kind of a breeze to memorize).
For the long tail of passwords that you shouldn't be memorizing in the first place, a password manager with a good configurable password generator is invaluable. I use Lastpass (I like the breadth of it's platform support: all major consumer OSes, all major mobile OSes, extensions for all major browsers). Alternatively, lot of people recommend 1password.
Diceware has better guarantees, but the password managers are usually much more convenient[1]. I weigh these costs and benefits when choosing which way to go for a particular use case.
[1] With the significant exception of passwords that will regularly have to be typed out on mobile, since diceware passwords are much more virtual keyboard friendly than random character generated passwords. This is partly because you can typically keep the entire thing in your head, not having to reference your password manager multiple times, and partly because they don't rely on special characters for their entropy, so can be typed out on the primary keyboard without switching to numeral or special character keyboards.
The reason I've been thinking about this, is that I'm not happy with diceware. Five words (64 bits of "guaranteed" entropy) is around 20 characters - and I'm not sure if diceware looses some entropy if you omit spaces (eg: "at hat" and "a that" both become "athat").
My main takeaway looking at the problem, is that 64 bits is a lot to encode in ~26 letters and maybe 10 digits - in a way that is easy to remember, easy to type, easy to read (if eg: given a printed initial password, read/hear (sharing over the phone/double as a way to read out a hash/shared key etc).
My main issue with diceware is the large number of words; almost touching on typical active vocabulary of even native speakers - never mind if your users speak little or no English. One benefit of the system above is that as long as you can come up with four/five sets of 128 words that don't collide among themselves in the groups of 128 - you can adapt the system to any alphabet and preserve any guarantees of entropy. Making a diceware wordlists is a huge undertaking by comparison. (But the benefit is that people have already done this for many languages).
For ease of typing. Typically you have to enter passwords verbatim - typically passwords need to be entered without error, blindly. 16 characters is easier to get right that 60.
And while it might feel good to pretend full words add entropy, if you assume the attacker knows your system - it really doesn't (hence "guaranteed" entropy).
As for diceware, I don't find those passwords easy to remember - especially past 60 bits of entropy. But use what works for you.
> And while it might feel good to pretend full words add entropy, if you assume the attacker knows your system - it really doesn't (hence "guaranteed" entropy).
It does: munroe's proposed scheme operates on the assumption the attacker knows it. The 11 bits of entropy refer to a dictionary of 2K words to choose from. The reason to type full ones is you're not hamstrung by the "no common prefix" limitation, which allows larger (and easier to remember) dictionaries.
Also, we're talking theory. Typing them blindly is an artificial implementation limitation imposed on us by bad software. Just like "you need at least one digit", "maximum length 16", &c. If you're going to consider those, that's fine, but then you're not talking about actual password theory anymore--you're just discussing how to cope with bad platforms.
Case in point: many good PW forms (OS logins, &c) have no such limitations, and offer a "view password while typing" option.
But there's a reason for hiding password input: [ed: making shoulder surfing a little harder]. Or unlocking a computer that's projecting to an audience. [ed: see also citizenfour where Snowden uses a blanket when typing in a pass phrase].
This is indeed not about password "theory", because experience shows that actual system (in)security happens where computer systems and users interact.
Using a common subset of keyboard layouts for different languages (limiting the character set), being workable on touch screens, are important for security. And using passwords at all is working around "bad platforms".
> The 11 bits of entropy refer to a dictionary of 2K words to choose from. The reason to type full ones is you're not hamstrung by the "no common prefix" limitation, which allows larger (and easier to remember) dictionaries.
From playing with this, I'm not convinced the tradeoff of using a big dictionary whose that cannot be enumerated by a short unique prefix (to reduce length) really adds that much - just like increasing the character set beyond 26/36 helps all that much - because you only gain a bit for every doubling in size.
My idea is for the mnemonic to form an actual "story" (in a secure way) - in the hope that it's easier to remember :
"boy flies angrily away" than "correct horse battery stapple".
A) that may be wrong
B) You still need too many words in order to encode a "high enough" entropy
> The 11 bits of entropy refer to a dictionary of 2K words to choose from. The reason to type full ones is you're not hamstrung by the "no common prefix" limitation, which allows larger (and easier to remember) dictionaries.
Another note on this - assume an average word length of 5 - that's 11/5 or 2.5 bits per character typed (again, assuming the wordlist doesn't loose some bits for "double coding" like "at hat/a that").
At 7 bits per word - of which two characters are enough, we type 7/2 or 3.5 bits per character.
Conversely, we only memorize 7 bits per word vs 11 bits.
Embedding special characters only makes it harder to remember correctly yet has little benefit. Your example is the same used in the xkcd where they explain this (except you've added an additional word at the beginning) so you've probably seen it already but I'll link it anyways. https://xkcd.com/936/
At work I constantly deal with people who can't remember passwords as short as 8 characters, you have to remember we're not representative of the average person.
Python 2 had an inherent flaw with character encoding. While passing data around, strings and bytes were treated as the same thing, until they weren't the same thing, at which point your software broke in horrible and unexpected ways.
Python 3 fixed it, along with some other less drastic changes. Despite a gradual and ever ongoing migration to python 3 by every major library (http://py3readiness.org/https://python3wos.appspot.com/), a lot of HN posters love to talk about how they'll never use python 3.
The secret is: no one cares. People still use java 1.4.2 and that hasn't impeded Java.
Python 3 was a large and backwards capability breaking change that required people to learn some minor new behaviors when writing code, but it has been and will continue to be the future.
Gotta ask you, though. How indignant are you about the recording studios using the term "sound engineer?" Or a hollywood post-production studio employing a "special effects engineer"?
I personally would like to retire the phrase "software engineer". This is partly because I think it's very important for software developers to get out ahead of this and avoid giving the various PE accreditation bodies the notion that they have a claim on software. Civil, Mechanical, hell, even Industrial. Go ahead.
But Software developers, if regulated, should stand apart from these fields. I'd rather see it regulated as a separate field, more like actuaries than a branch of engineering.
In short, software developers should drop their claim to engineering, but engineers should drop their claim to software.
Before you think this is a groundless concern, keep in mind that the patent bar has essentially legalized patents on mathematics while excluding mathematics as an acceptable background for reviewing patents. Seriously, the charter for the patent bar specifically mentions mathematics as coursework that does not qualify you to sit for this exam.
The very low quality of patent review reflects this. I could see a PE takeover of software as being similarly destructive (actually, far more destructive).
It does make sense as part of cartel building, though - expand your monopoly, restrict your competition. Regulate mathematics, exclude mathematics degrees. I could see something similar happening in software development, easily, with greater harm.
There is a widely accepted difference in the US: the PE exam. Other countries make it flat out illegal to call yourself an engineer without the proper credentials.
They're dressed up versions of "correlation != causation". Low thought comments appealing to people with not-even stats 101 knowledge.
There is no such thing as a perfect study, and a generic version of the OPs comment could be copy and pasted on any study ever. Unless you study the entire population of the planet, you're going to miss subgroups. Unless you study the entire population of the planet, you're going to need some sort of selection criteria. Unless you have infinite funding and time, you're going to need to make trade offs and sacrifices in your experiment design.
A study will disclose these shortcomings for readers to balance the significance of results against.
Take this complaint from OP:
>* The sample size was tiny. (20 students)
What sample size would satisfy him? Why is 20 too small? 40? 80? 1037? Is he basing his opinion of a proper sample size on his gut? 20 just doesn't feel right?
