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 use javascript to follow the viewport
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
https://security.stackexchange.com/questions/53481/does-face...
"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)
Why?
http://www.postfix.org/postconf.5.html#allow_untrusted_routi...
example+Youre+the+best!+Around!+Nothings+gonna+ever+keep+you+down@gmail.com
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 ([email protected]) - 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 protected] and turn that into [email protected], and it offers [email protected] which it will deliver to [email protected]. So here we already have two new conventions that sites can't possibly detect as alternatives to the normal [email protected].
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.
Incredibly frustrating.
For Firefox, setting the "dom.event.clipboardevents.enabled" about:config option to false prevents clipboard paste events from reaching javascript. No more blocked pasting after you toggle that option, even if the website attempts to do so.
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
on alfred_script(q)
tell application "System Events" to keystroke q
end alfred_scriptThis 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.
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.