10 ms·
Honeywords: Making password-cracking detectable
- peterwwillis 13y agoMaybe i'm crazy, but I really hate PDFs. Why don't people at least provide an HTML or text copy next to their PDF?
- jfb 13y agoConversely, I prefer PDF, because, particularly with LaTeX generated content, it just looks way, way better than HTML.
- justx1 13y agoThat's what "Cheif [sic] Scientists" do
- bluedino 13y agoThat's how academic papers are done. One reason is that it's more complicated to do mathematical equations and such in HTML (we don't even talk about text) than it is to simply use LaTeX.
- peterwwillis 13y agoI understand the need for proper formatting in academic papers, but it wouldn't hurt anyone to provide a text copy after the fact. If someone needs a formula they can render the pdf. But a secondary text copy can be more easily indexed, searched and viewed on any kind of text-viewing device... it's just a million times more convenient.
- bluedino 13y agoI understand what you are saying but it's a pretty safe bet on today's internet that a browser is capable of handling a PDF. An online service such as http://www.extractpdf.com/ http://www.extractpdf.com/ does a pretty good job of taking the PDF link and extracting the text.
- scott_s 13y agoIt "hurts" in that it takes time. It's also not just math, but figures as well - diagrams and experimental results. There are automatic Latex-to-HTML programs, but their results are not pleasant. And I have difficulty putting up things that are ugly.
- psychometry 13y agoMainly because most math/CS papers have a lot of LaTeX in them for equations and symbols, so it makes sense to write the entire paper in LaTeX and then convert to PDF or PS.
- _delirium 13y agoIn recent Firefoxes, they get transparently converted to HTML by PDF.js, so I don't tend to care too much either way. There's a little bit of conversion overhead, but then there would also be some conversion overhead if they were using MathJax.
- acqq 13y agoAnd I enjoy PDFs on my Retina iPad. Much better than other text representations, almost sharp as on the paper, the screen format matches the paper format, it's easy to move the whole PDF to iBooks for later reading. Perfect.
- ANTSANTS 13y agoA similarly off-topic question: Why isn't "automatically crop margins" a standard feature on all PDF viewers? I don't care if it perfectly matches the way the PDF is supposed to look printed out, I just want to read the paper. I can scroll through web pages and flip through PDF pages just fine, but I loathe mixing the two metaphors, so I have to be in "fit page" mode. I'd find entire pages of PDFs perfectly legible on my 11' netbook or 6' e-reader, if only the damned things would crop out all of that wasted blank space and use their entire screens for the content. No, the zoom feature on most PDF readers is not adequate, because you then lose the ability to progress exactly one page forward and backward at a time (at least, this is the case on every reader I've used). Not to mention, who wants to do that manually every time they want to read a paper?
- poxika 13y agoIf the Honeychecker system has to be secured in order to guarantee that the whole system is secure, why not store the encrypted passwords there in the first place ? It seems to be manufactured complexity.
- ianferrel 13y agoIf you keep the encrypted passwords in one "secure" place and the honeychecker in another "secure" place, then the system is secure unless both systems are compromised. It's classic engineering redundancy.
- marshray 13y agoExcept that: A. It doesn't do a lot to 'secure' the password credentials (in the way most people think of the term). It just tells you that someone tried to login with a honeywords. What happens then is a difficult process. B. It's only belt-and-suspenders redundant to the extent the difficulty of cracking the honeychecker server is independent of the regular login server. It's certainly beneficial that it has a much simpler API, but if your honeychecker is just a different Ruby Gem hosted on a different Linode (for example) the benefit are lessened.
- newscasta 13y agoIf the honeychecker is compromised you are no worse off than without a honeychecker (unless it lulls you into a false sense of security) but as long as it's not hacked it adds detectability. Not sure it's worth the effort but it's an interesting idea.
- anonymoushn 13y agoIndeed. Their FAQ says as much in question 6, and question 7 tries to make it out as though it maintaining a separate (actually secure?) honeychecker actually worthwhile pursuit, because then attackers who don't bother to look at your login code after compromising your box can sometimes be detected. It seems like a bit of a longshot, though. I would expect the attacker to be at least a little curious as to why each user has 20 passwords.
- 13y ago
- yeison 13y agoThis is such a simple, yet powerful idea. What an elegant way to add another layer of security to a system. It's very easy to generate long random passwords that no user would create on their own. Then to populate the database with a large number of these phony passwords. There would be a small hit based on the amount of space the honeyword passwords occupy. However, the amount is manageable, and the benefits are well worth it.
- jrabone 13y agolong random passwords that no user would create on their own Really? You see the ones my IronKey comes up with... I have about 140 of them. IMO anyone using a password manager is pretty likely to be generating long, random passwords, or they're Not Doing It Right.
- deckar01 13y agoI am working on a replacement for password managers. Type a password, then [Ctrl] + double click the field to hash it. Even if the database is compromised, an attacker is unlikely to assume your plaintext password is a base64 hash. http://deckar01.github.io/SHA512JS/ http://deckar01.github.io/SHA512JS/
- deleted 13y ago[deleted]
- nickzoic 13y agoPersonally, I suspect the Right Way to do this is for W3C to standardize a special input field something like: <input type="passhash"/> which looks like a normal password entry field but automatically does some clever hashing on the client to create a per-site password. Of course, you can still get keylogged if you use a public computer or whatever.
- yeison 13y agoWell, the issue I'm alluding to here is the issue of avoiding collisions. Even the password generator will not create the same long random passwords precisely because they're random and long... So even with a password generator these are still long random passwords that no user would create on their own and therefore do not collide with the honeyword passwords. Also, the combination of password generator and honeyword is actually even more secure than either one; in a "Greater than the sum of its parts" kind of way.
- cheald 13y agoSince the whole system turns on having a hardened system which can distinguish honey from true passwords, it seems like you could get a significantly improved level of security by replacing it with a hardened system that hashes passwords with a secret, long pepper, which vastly increases the amount of time necessary to crack even trivial passwords. The alarm trip is nice, but if you assume that you have a hardened black box that you can put data into and get data out of, you could use that to increase the complexity of the given hashes to a degree that they would be uncrackable (offline) in the first place, and standard throttling (and alarming) makes online brute-force attempts trivially detectable and blockable. Assume that you have a user whose password is "1234", and the salt is "5678". Let's assume the system is naive and uses SHA1 for hashing. Given these two pieces of information, that password is trivially crackable. Not a problem. However, let's now assume that we take our password and feed it to our black box, which hashes it with a 1024-bit pepper, and feeds the resulting hash back to the web app. Assuming the pepper's secrecy is protected, the password's complexity is now so ridiculous that even with all the computing power in the world, you wouldn't be able to brute-force the hash for the password "1234" before our sun explodes. Now your passwords are mathematically protected against breach, which is arguably more valuable, since it means that the attacker can't take my email address and my six honeywords + real password and plug them into various sites trying to get a hit - those other sites won't know which are the honeywords, and won't trip any alarms when the wrong ones are used, but given the tiny quantity of passwords to try, attackers are sure to get hits. Why not just prevent them from ever discovering a usable password in the first place? Or, if you wanted the honeypot aspect to be preserved, make your black box take a password, perform some transformation on it, then hash it. For each user, we'll generate and store (in the black box) a one-time pad that we use to transform (/encrypt) their password, then hash it. Password complexity isn't affected, but without the pad, the original password is unobtainable. My bad user uses a 4-character password "abcd" which maps to "hvz5", which I then hash. An attacker who steals the hash list can brute-force "hvz5" easily, then attempt to log in with it, and my system can detect an that the attacker is attempting to log in with a transformed (and thereforce, obviously derived) password and raise the alarms. The system allows for detection of compromised logins without ever risking exposure of the user's actual password to an attacker.
- tptacek 13y ago
- jdechko 13y agoI didn't go to MIT, so I may just be talking out my ass here, but here goes. While I think this is a good step in the right direction, there is no technological solution for the real problem: AVERAGE USERS ARE IDIOTS They use dictionary passwords. They write them down on post-it notes. They re-use passwords. Try as we may to enlighten people. They are still stuck in their ways. The only thing we can really attempt to do is force people to add complexity (#1). Security is only as strong as its weakest link. I'm glad that companies take my security seriously, and I hope this idea catches on to strengthen that security. But it's only a small step overall.
- bluedino 13y agoThis doesn't try to solve any of those problems - it's basically a honeypot system to detect when a password file has been leaked and logins are being extracted (and used) from it.
- khafra 13y agoIt certainly helps when we use password-based key derivation functions instead of cryptographic hashes in our applications. The difference between md5 and bcrypt with a high work factor is like the difference between Pa$$word01 and t8LIO.>5row8VEgf
- jfb 13y agoUsers aren't idiots. They're trying to get shit done, and these stupid and arbitrary rules about passwords are hindering their ability. They're stuck in their ways because holding the computer's hand is a waste of time. Forcing them to add complexity has already failed, because fundamentally it's not a humane solution to the problem.
- vec 13y agoThis times a lot. I'm far from a naive user, but I recycle a handful of easily memorable passwords for most of the services I subscribe to. And I'm willing to bet that most of you do too. Security is a tradeoff, and we tend to forget that complex, unique passwords have a very real cost. They drastically increase the risk that I will lock myself out of some service, and dramatically increase the workload of authorizing myself when I do want to use it. With a few obvious exceptions, this tradeoff is a huge net loss for the average user. In other words, the risk of some stranger wanting to post as me in HN is acceptably small. The cost of having to install KeePassX, then download my passwords file from Dropbox then decrypt and copy/paste, then make sure the paste register is clear, then securely delete my passwords file every time I borrow a friend's computer is prohibitively high.
- ss64 13y agoIt's a good idea but avoiding collisions with genuine passwords could be tricky particularly for sites with millions of accounts. If the honeywords are very long and random, then they probably won't collide but they will be obviously different from a typical users password. If you add a standard prefix or an extended character that is disallowed for real user passwords, that avoids collisions but also makes the honeywords easy to filter out. If you generate the honeywords by swapping around the characters in a real password then theres a danger that a user could set off a false alarm with a simple typo in their password.
- takluyver 13y agoThe generator shown will produce random variants on passwords it's fed, so it shouldn't be easy to filter them out. False alarms should be easy to avoid - stick 100 honeypot passwords in the database, and set off the alarm if say, 10 of them are tried within a week. Obviously those numbers can be tweaked according to password strength, number of users, etc. Edit: It's actually talking about a specific set of honeywords for each user. So when the password is chosen, you generate a set of honeywords that are quite different from that password, and can't be reached by mistake.
- anywhichway 13y agoThe way the system is proposed is that each user would have an exclusive list of honey words for just them. Each user would have, say 10 possible passwords. The password system would recognize all of them as correct for that user, but only 1 of the 10 wouldn't also trip an alarm in a secondary system. The honey word generating system avoid collisions with that specific user's password for generating that user's honey words, which is all that is needed.
- anywhichway 13y agoThe way the system is proposed is that each user would have an exclusive list of honey words for just them. Each user would have, say 10 possible passwords. The password system would recognize all of them as correct for that user, but only 1 of the 10 wouldn't also trip an alarm in a secondary system. The honey word generating system avoid collisions with that specific user's password for generating that user's honey words, which is all that is needed.
- adnam 13y agoListen carefully, that is the sound of foreheads being slapped.