I hate sites that do that (or prevent right-click as if that somehow secures their code).
- copy/paste hijacking
- sensor access: microphone, camera, GPS, etc.
Maybe even go further and introduce some sort of rate-limiting for
- XHR requests
- relayout events
to save power and data.
I _think_ that means it can send all of by passwords offsite, or do plugins need a separate permission to phone home?
The plugin's code is probably quite short - maybe you could inspect it yourself, manually?
It's a bit disappointing that Chrome doesn't let you sandbox things well enough to install plugins safely; there's no reason that plugins should be allowed to transmit data without asking for permission.
This ties in to the discussion of Craig's List the other day. It is so refreshing to use a site that doesn't try to be clever. I understand if people find it ugly, but I don't - simple is good, and I don't care if sites follow whatever design trend is hot this week. Usability is far more important.
I think that option is going to greatly constrain where you are able to go on the web. The vast majority of ecommerce sites I visit will break with JS completely turned off.
At one point, I built a sortable filterable table for an admin UI, using React. One of the admins was a "no js" guy, and he thanked me for building the whole thing in functional HTML. Up until that point, I had no idea that the admin side of the system was even usable without JS; that was just a natural consequence of optimizing for SEO and load speed (server side rendering, URL representation for all significant state).
My experience is, that while ecommerce sites may break, most of them are quite usable even without JS.
Most good blogs work just fine. And the ones that don't I usually don't bother reading.
I roughly use OpenStreetMap 80% of the time, Bing 5% and Google Maps 15%.
Looking up where an address is? OSM. Routing? OSM. Opening hours for places I go semi-regularly (but not often enough to remember them)? OSM (I put them in myself). Footpaths, caves, info on towers (like GSM/3G), public transport routes, etc.? OSM.
Aerial imagery? Bing (much faster than Google Maps).
Traffic info? Google Maps (I'm still casually looking for alternatives). Searching a shop? Google Maps.
In the Netherlands OSM is of equivalent quality in some categories (road network, addresses), better quality in others (trails, meta info about towers or cave entrances or so), or worse in yet other categories (information about businesses, at least outside of city centers).
I don't use Google services in my personal life. (I have less control over vendors at work.)
I also use extensions to enable them on certain sites. Just tap the extension icon and it will reload with JS enabled.
You'd be surprised how fast webpages load without JS
So basically you don't use 80% of the internet because the occasional site annoys you?
Do you also cut off your hands when you get dirt on them???
1.) typing it out manually while you can't see if you made a mistake
2.) using developer tools to set the 'value' attribute directly
"SPP" discourages use of a password manager. End of story. I also see this pattern used on banking websites for inputs like an account number. This drives me crazy as well for the same reason. The computer can get it right more reliably than my eyes and fingers.
Whenever I see a website that blocks paste I immediately assume it's built by incompetent people and trust it with as little as possible.
Only works with Internet Explorer
Doesn't work with Internet Explorer
Password must have one of 4-10 special characters, but not other special characters. (e.g.: Must contain !, @, ^, &, or parentheses, but not ;, ", etc)
Passwords have no requirements
Right-click is disabled
Video plays as soon as the site loads
Share buttons that pop up over every single image
"Want to see more" when you move the mouse to the top of the screen (Or reach the bottom of the page) (or as soon as the page loads)
Slideshows of any sort
Except.. it can only be 8 characters long. Anything else gets truncated (they explicitly said so). The mind boggles.
I have no idea where this limitation comes from, do people just set an 8 character field in their database? Was this a problem decades ago that they figured they'd save a few megabytes of storage space?
I think they've finally changed it so that the reset period is determined on your password complexity, no length limitations, and you can have 2FA (or at least mobile password reset).
That's... not necessarily the case. You can implement that check by only storing hashes of previous passwords, or of patterns derived form them that are also forbidden (e.g. store a bcrypt of every previous password converted to all lowercase and with numbers and symbols removed).
Developer: Similar passwords? Or Same passwords. Similar is hard.
M: Similar. Can't let people be lazy with their passwords.
D: Well, if we really have to do it, I guess we could store a bunch of hashed variations of the password, but...
M: Good! Let's do that.
D: ...but that could be a massive amount of space for long passwords.
M: Okay, we'll just enforce short passwords then.
D: ...doesn't that more than negate all the benefit of preventing similar passwords when rotating them?
M: Doesn't matter, the CEO said he wants this. Hop to it!
Developer laments the stupidity of their life
Why not generate a list of similar passwords to the new password, hash them all using the same salt of the previous password and then compare them.
Still, permutations longer hashes don't require substantially more space. Password storage is a completely trivial fraction of total storage -- Compare to a single photo, or a video!
And further still, they don't need to _store_ all the hash variations
"Is the same as" can be fine with a hash, but "Is too similar" is definitely a red flag.
Though another way around it is to apply a set of common transformations to your new password, hash it and see if it matches the previous one. I.e. if your current password is "Password123" and you try to set it to "Password1234", the system could truncate the last digit on the new password and see if it matches the current one.
I'm having trouble imagining what scenario client-side hashing would protect against.
-- edit: using a KDF would improve it even more.
If you store the hash of the password, plus the hash of a hundred "similar" passwords, then the hacker only has to brute-force one to find that they are on the right track, and then brute-force "similar" combinations.
man 3 crypt => https://linux.die.net/man/3/crypt
That prompted me to google up a summary of the password length limits of various operating systems https://security.stackexchange.com/questions/22721/password-...
Internally they still use Lotus notes 7.? last I heard. And storage limit was something like 100Mb if I recall correctly.
In my experience as a user, most people in the end also validate the email address by sending an email, but do no learning.
(Obvious caveat being that any provider can trivially append @provid.er if you don't specify, so this isn't really proof that email is specified that way.)
And if you try to actually use a bare TLD you will crash hard into collisions with unqualifed domains and search paths. So, fun as a hack to amuse fellow techies but not useful for anything real.
should satisfy you both right? I use the original or a form of usually when I had to check emails.
dot-atom-text = 1*atext *("." 1*atext)
Too bad the music emoji is stripped by HN!
PS: Emoji in titles also make things like Youtube videos and blog posts pop quite a bit when shared via social media.
While I believe the + was common for postfix, exim and sendmail?
There even was a spam-fighting scheme that used this - it took a key, and optional date, and a sender address - and generated a unique address you could give out, that was only valid for a certain time, for a certain set of senders.
If the system received a mail with a from address that didn't match the cryptologically signed to-address (firstname.lastname@example.org) - the mail was held back, and the system generated a reply, with a signed reply-to address. A sort of manual grey-listing.
Similarly, mail providers can come up with all sorts of different conventions if they want. For example, when setting up a new domain in FastMail, it offers the ability to accept email@example.com and turn that into firstname.lastname@example.org, and it offers email@example.com which it will deliver to firstname.lastname@example.org. So here we already have two new conventions that sites can't possibly detect as alternatives to the normal email@example.com.
I made a saas tool for mac developers. Fixing all the quirks would cost far more than the potential 2% users are worth to me.
Slideshows - you mean even embeded Slideshare ones? Why? It's a good tool to explain certain ideas, and easily shareable one. We had our slides embeded on a TC post, and we used them as a significant source of traffic.
There was once a time where this was a workable excuse, but today's browsers are actually pretty good about following standards. If you're doing something that works in some browser, but not all, then you're likely exploiting some weird quirk of that browser.
And of course, not testing if it works in x browser is different than actively stopping your webapp from running if it doesn't detect the right browser/os combination.
I don't know what your product is, but I use four different browsers on a daily basis across three operating systems (it would have been six across 2 if not for the win10 privacy debacle, and even more if I had an android), and I want all my SAAS to work on all of them.
Experience says when they don't work everywhere, IT just dumps the service for another SAAS provider and everyone cheers.
I forget the term I did this with openssl, Apache, I think with a cheap vps I get between 9 and 10 cost, bcrypt. Sorry if these are not directly related for hashing.
A few sites I have to use for my dishwashing job work ie. share point and a card company that manages my money, as well as another by WalMart, they don't allow special characters only upper case-lower case and digits. You'd think okay length then but some have limits like a 15char limit.
Or people will use 2-4 character passwords (often the initials of their name etc)
That seems like it's asked with the expectation that the obvious answer is "no", but I believe it's "yes". Well, I have no idea of the quality of their devs, but someone in the decision chain thought that auto-playing videos was a good idea, and he, she, or they were wrong.
We don't optimize for impressions per session. Instead we optimize for the number of things a user does in a fixed amount of time, (or per session). The former is a poor proxy for the latter, and you can increase impressions by adding useless click through pages that ultimately drive away users and destroy your business in the long term. (In the short term, these things make your metrics look good.)
I bring this up because slideshows are a great way to artificially boost impressions.
Some of us just can't be bothered. My web app is tested on Chrome, Firefox, and Edge. If you want to use IE you are on your own and I won't support you unless you give me a million dollars.
Banks figured the cost of reimbursing people if their account is compromised is lower than the cost of having to field all of those phone calls.
Source: Used to work at a bank.
Once after my account was stolen from, I did a careful look at the website and sent in a list of questions and complaints about their practices. After enough bugging, a person eventually called me. The bottom line was essentially that I shouldn't be concerned because I'm not responsible for fraudulent withdrawals. It wasn't very satisfying.
The thieves got away with around $2400.
I believe I read that Facebook stores a few commonly mistyped versions of everyone's password. Actual password, typed as if caps lock was on, things like that.
I love how it's always the banks with these ridiculous password practices. I'm really glad that it's not some site where the password is protecting important information.
But if you use bcrypt you can partially compensate by using a higher work factor.
The 'correct casing' is any member of the set of all permutations of cases. So you both do, don't, and do not care.
However; I worry that this is a very BIG assumption.
Even in my IT-literate circles password management usage is low.
In my non-IT circles it is non-existent, and not because of SPP particularly; I suspect SPP (which I agree is silly) derived from an understanding that allowing an average person to paste passwords meant they stored them in passwords.txt on their desktop.
Naturally the population here is technical so it can be hard to see that as a common and sensible thought process. But never underestimate the capacity of the average person (who's IT capability you and I don't represent) to make mistakes like this and never see the problem/risk.
It's odd that the article explicitly mentions this near the start but then doesn't address it in the Justifications section.
That's a significantly better practice than using the same easy-to-type password on every site, isn't it?
But that is password management, it's just crap password management.
There's certainly an argument that a plaintext-on-desktop stored list of high-entropy passwords is better than a single in-(human)-memory low-entropy password. With the recent wannacrypt reminder, that argument's slightly diminished, though.
I think the highest impact (i.e. fn of quick/low effort, high reward) suggestion to non tech-literate folk is to use 2FA on their email account. I like and usually suggest Authy, mainly because it's available as a Chrome app too whereas e.g. Google Authenticator is just on Android/iOS. (I assume it's clear, but email account as opposed to something else since it's so near universally treated as the fallback option.)
That's a good base for them to start using 2FA everywhere else it's possible, too.
You are forked if your manager is ever compromised. It's only a matter of time until a major breach happens with a popular password manager.
You are forked if your machine is ever rooted too. Security isn't about perfection, it's about economics and threat models. For the average person the biggest fundamental risk comes from one of the vast numbers of services they use, none of which they have the slightest control over or knowledge of, getting breached, bought, leaked or whatever. As long as we need to use passwords (long past any technical reason for it, but legacy and inertia tends to make change extremely had) for authentication, it will in turn remain necessary for people to use passwords for every site that are good (random of sufficient length), unique, and can be changed at any given arbitrary time (in case of service compromise). It is simply not possible for most humans to handle all that in their heads, perfectly and indefinitely. Which in turn leads directly to password managers, end of story. It's not a matter of them being ideal or even desirable, they're necessary under current common authentication practices.
>It's only a matter of time until a major breach happens with a popular password manager.
Explain what you mean by this? Most password managers operate purely client side, and all actual password managers perform encryption client-side, there is nothing to "breach" to get general access to a wide swath. A persistent targeted threat is an entirely different scenario. Or did you mean you expect the password manager application software deployment system itself to get breached and thus release a malware infected update? That though isn't an issue limited to password managers at all, it's one that you can at least somewhat counteract yourself since it's ultimately on a system under your control (and there are OSS password managers, etc), and password manager devs have better domain knowledge and specialization then some random service.
In terms of threat model it's a no brainer. It's disappointing to see continued protestations against password manager usage on HN of all places, short of some theoretical discussion of switching everything to proper public key auth. Even a full court industry push starting tomorrow though wouldn't eliminate passwords for likely years if not decades, and in the mean time everyone has to make the best of it.
For sites that disable pasting, I have developed quite a skill at copying the password character by character from my PM into the password field. I'm even starting to remember a couple of them.
My password manager also clears the clipboard if it is equal to the last password copied after a wile (I've never timed it).
I'm trying to understand the reasoning for this. Are you dealing with very sensitive information that you have a real reason to fear the rubber-hose cryptanalysis method?
Although, honestly, the other part seems more bizarre. Gov't agencies and other clients are just giving you their sensitive passwords, and trusting you to delete them after the project, at your leisure? How is that not terrible security? Revoking a consultant's security needs to be in the hands of the employers.
But why even know your own passwords, what is the point? If I can double click from my manager and paste it into my password field and never have to worry about knowing anything, I'm much happier and safer.
The AppleScript in question is very simple, it just looks like
tell application "System Events" to keystroke q
This makes me wonder about the personal security practices of the team that built it -- it's unlikely they typed strong passphrases hundreds of times a day during development -- and whether a secure site could come from such a team.
There are regulatory bodies that require regular challenge of user identity for approving items as sort of a signature mechanism. This is another time where active thwarting the password manager makes sense. Whether or not the regulation makes sense is an entirely different issue.
In the token case, I wonder whether they should have been password fields to begin with. Replacing a 6-digit OTP with asterisks is of questionable benefit, because the shoulder-surfer it thwarts can't reuse the OTP and is really unlikely to swipe it and use it before you do.
Oh, and if you forget your login/pass/security-answers, don't worry, you can just re-register your account with the same username as before, with all new password, security questions and answers.
As in... every login it wants you to answer all six of your questions? That's barmy.
eg. echo "type password" | xdotool -
This is my pet peeve. Password fields should not be obfuscated by default. It should be a toggle that is off on page load. Shoulder surfing is a corner case.
if you can remember your password, its probably too weak
hunter2 is the password manager I wrote for this: https://chiselapp.com/user/rkeene/repository/hunter2/
Now I use a hardware token (yubikey) to store my PGP key so I can use a relatively weak PIN code on it (since you need to have physical access to the device to use it and you only have 3 attempts before it locks up). It's a pretty good quality of life improvement.
Then you better don't use it when you're fatigued or drunk. I nearly locked my SIM card once by not realizing until the third attempt that my phone was asking for the SIM card PIN rather than my lockscreen PIN.
Well, unless I'm silly enough to try and bruteforce that PIN as well, after 3 failures I'd be left with an expensive piece of plastic... Fortunately I'm rarely that drunk.
EDIT: Actually as the sibling comment points out you can still reset the token even if you mess up the admin PIN. So at least you won't "brick" your token completely.
As XKCD famously pointed out, Diceware-style pass phrases can be both secure and memorable. XKCD's four word example isn't secure when fast brute-force attacks are feasible, but eight words is still easily memorable and secure enough for anything. The important point here is that "random words" really does mean "random", i.e. not picked by a human.
Diceware, 6 words 2.2 x 10^23
Diceware, 5 words 2.8 x 10^19
Diceware, 4 words 3.6 x 10^15
a-zA-Z0-9, symbols, 10 4.3 x 10^19
a-zA-Z0-9, 10char 8.4 x 10^17
a-zA-Z0-9, 8char 2.2 x 10^15
Diceware, 6 words 77 bits
Diceware, 5 words 64 bits
Diceware, 4 words 51 bits
a-zA-Z0-9, symbols, 10 65 bits
a-zA-Z0-9, 10char 59 bits
a-zA-Z0-9, 8char 50 bits
It's highly amusing when a site tells me that such a password is insufficiently complex, given that it will never in the lifetime of the universe be guessed.
The entropy calculations are probably generous. The wordlist isn't as long as it looks, because some of the words are strange and people tend to re-roll if they get something like that. It's probably better to assume there's only 1000-2000 "words" people will safely combine.
Also, the combinations list assumes that the attacker knows the method/word-list used to generate the password, which may not be foreknowledge the attacker has access to, especially in cases of giant many account password brute forcing attacks.
Just because your passphrase may essentially be a PIN look up into a lookup table doesn't mean the attacker knows that or has access to the same lookup table.
You can also add additional entropy via punctuation or casing.
The point to a random passphrase is to try to avoid "human" mistakes like over favoring a subset of words, and rerolling words you don't like potentially makes your collection of passphrases more susceptible to analysis or social engineering (word association) attacks.
Like I said, it's generally better to pick a word-list you are comfortable with all the possible words than to subset a word-list you aren't entirely comfortable with.
The goal of something like Diceware is to be easy for humans to memorize but also still true random (see: xkcd's battery horse comic). If you don't need to memorize it, then yes, why not entirely generate a random sequence of letters/numbers/symbols/emoji.
> Distributed_By: WalgreenCo. 200 Wilmont Rd.
And it would both be very strong, and be difficult for someone at my desk to guess by looking at things on my desk.
- If it's a website I couldn't care about, I use a simple password, probably a remnant from growing up.
- If it's a website I'm concerned about but knowingly won't use, I create a random password and clipboard it during initial creation/login, then every time I use the website I reset it (lazy man's password generator)
- If it's a website that I care about, like HN, I have a loose pattern that I follow that includes symbols and numbers (that's the 30ish character I was referencing). Every website is unique.
- Financial accounts have their own set of rules (unless it's stupid and has, say, an 8 character limit)
- My main email accounts get special treatment with an exceptionally long password.
- Use two-factor authentication wherever possible.
And yes, I could replace this with:
- Password manager
- Two-factor authentication
For instance, if I needed a new strong password, I could use, "This#jar#once#held#1111#M&Ms,#but#now#it#is#empty."
The only thing I need to remember there is the story of the jar and the padding character I used in place of spaces. If I really had to, I could put "#" on a sticky note under the jar. But of course, I can't use that password now. So I might instead use "I(used(this(jar(as(an(example(on(HN." But now I can't use that one, either. So maybe I use "These!blinds!are!very!dusty.!!Someone!should!clean!them." or "My^dog^once^killed^a^dozen^baby^rabbits^in^the^tall^grass^I^didn't^want^to^mow." or "MyFgreatFauntsFhadFreallyFlongFhair."
I get really irritated when sites tell me I have to include numbers, uppercase, lowercase, and symbols in the same password. I get especially irritated when they put an upper limit on the number of characters, or ban certain characters from appearing in the password.
But everyone has their own tricks for remembering things.
And I certainly don't make the effort for sites that I don't consider to be important. Those as often as not just get reset via e-mail whenever I forget my password.
Use a password manager. KeepassX is free, cross-platform, works on phones, does all that work for you, secures even your least-valuable accounts, does things right, doesn't store your passwords "in the cloud" and you'll get to keep applying your scheme to your master password.
Why would anyone do that, when those digits can so easily be calculated or referenced from data files? Why do anything that is not strictly necessary? Why try to bench press more weight than last time? Why try to improve your chess game? Why learn a new programming language?
Because different people like different things. I am not required to like the things you like.
And I like proving to myself that I still can remember things without a helper daemon to keep track of them for me. I like that little bit of paranoid fantasy I have that makes me think that the men in black suits would have to take the pipe wrench to my kneecaps to get at my passwords, so I don't think about how the security at all these sites requiring password is so piss-poor that it would be easier to bypass all passwords in lieu of cracking just one of mine. In the end, the problem mentioned by the article is that very few people implementing computer security measures have any idea how to truly secure their data, so they do stupid shit like block clipboard pasting into password entry fields, or allow accounts to be hijacked by a spoofed SMS 2nd factor, or try to roll their own crypto without the requisite number of CS and math PhDs.
Probably the best argument against spaces is the attack that listens to the sounds of your keyboard with a microphone as you type. As the space bar is a larger key, it sounds a distinctively lower note as you type, and would give even an unsophisticated attacker the means to determine the word lengths in your passphrase, which might reduce its entropy to something guessable within the lifespan of the universe.
Probably not a concern unless you might be targeted by someone with government-level resources.
The argument I am making is that your average passphrase — yes, including "correct horse battery staple" — could be cracked a trillion times over before a password generated via 1Password would be!
If you're using about 8000 words, randomly chosen, then a 4 word passphrase is about the same as an 8 character random password. (And in fact, for 8k words, it's basically a direct substitution between 2 characters and 1 word.)
For most intents and purposes, 8-10 characters is fine, and 20 characters is enough to use as a cryptographic key. Similarly, 4-5 words is fine for most uses, and 10 words is enough to use as a cryptographic key.
So I'm not sure what you think isn't effective about passphrases -- they're just using a 2^13 sized alphabet instead of a 2^6.5 one, but either is capable of being used to write down a random string of bits.
If they disabled pasting, I'd disable my account.