Hacker News new | past | comments | ask | show | jobs | submit | more bob_roboto's comments login

How would that work in this setup?


If Facebook were required to hash and salt phone numbers, then the correct 2FA value might still work (it would match the salt and has), but an arbitrary list of submitted values would be expensive to match to the hashed set.

Facebook would be unable to contact the user via SMS, they would have to issue a token via WWW or app and have the user text that to a specific address from the corresponding phone number to achieve phone-based 2FA. This might even be a third-party service to deny FB any direct access to the phone number.

The verification channel might become a phishing target via spoofed FB pages or apps, though that would be moderately expensive and of limited use. An attacker might request FB login credentials (the actual verification would not), might acquire a phone number (generally, though not always, a non-critical datapoint), and would still be denied account access via 2FA without further compromises, say, social-engineering the phone account (a proven risk, though expensive at scale).

Tildes.net uses a similar mechanism for recovery email addresses.


That's simply not true. Many European countries have privacy laws that render credit scoring agencies effectively useless. And yet it's not at all hard to get a credit card.


AWS Athena does thesame and is fully managed. Works reasonably well unless you have lists with complex objects in them.


There is so many more examples. Also hardly any of the links in the web version have an URL behind them, so you can't just open them in a new tab when researching something. Arguably one of the core use cases of a map application.


Used Tyk with a similar experience. Generally very happy with it but the documentation was, at the time, a bit challenging.


Hey Bob - you'll be pleased to hear Tyk took that feedback on-board. There is now very comprehensive documentation and user-guides. And true to the Open Source approach, anyone can contribute to them, the community have been great in working to improve them.


Great job! The search can probably be improved. Searching for "Cedric" without the accent aigu (é) does not yield any results, despite there being several Cédric in the database. If this was an educational project I recommend spending some time on search methodologies since they are very interesting. Start with using something like Levenshtein Distance and improve either performance or accuracy from there. Otherwise just use one of the existing open source libraries.


Why would you treat e and é the same? Those are two different characters with different pronunciations. You also wouldn't treat capital i (I) and small L (l) the same just because they look similarly.


Accents are generally considered unimportant in the context of a search, at least in French.


It's not just that é looks like e, é is the letter e with a diacritic [1].

[1] https://en.wikipedia.org/wiki/Diacritic


In addition to the other replies, this is important for input by keyboards that are not languages with that accent. Us “dumb” Americans don’t know how to type that off the top of our heads.

Or on mobile. It’s a pain on many devices.


Having had to go through public interview processes (i.e. not being approached by the company or referred) recently for the first time in a while I can't agree more. Take home assignments are fine _after_ an interview. Companies that send you a take home assignment before they want to talk to you are a waste of time and quite frankly, it's rude and shows a lack of respect. The ultimate insult being not getting back to you even though you scored the maximum on their silly CS undergrad tests.


> The ultimate insult being not getting back to you even though you scored the maximum on their silly CS undergrad tests.

The score is always too low and there are always some tests failing. Just submit the tasks blank or with dummy code. This way they waste time and money for the license - that's the only thing one can do in defence.


I find it more insulting when the rejection letter is poorly written and fill of grammar and spelling errors.


Ultimately this probably helps increase the overall internet security. Although in recent years it was available from a TLS secured source [0], the putty.org site (which might or might not be operated by the maintainers) is still not https secured. Given that probably tens or hundreds of thousands downloaded it from there (imagine, getting an SSH client from an unknown source!) I'm surprised not more happened. Other than that, thanks for the great work maintaining this project which helped me and others a great deal throughout my career. Countless times have I been stranded on a Windows server and quickly needed an SSH client.

[0]https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.ht...


Putty binaries are all signed, which is what you should be looking at when authenticating a release. Whether you fetch them over SSL is of little importance.


You are, of course, absolutely correct. And I hope this is what internal package maintainers in large companies and individuals using putty as their standard SSH client do. However, for many of us putty is a backup when they are not on their linux/osx machine and just quickly need an SSH client to do something. The workflow there is google->putty->first result->download->execute. You absolutely shouldn't, but we also shouldn't drink and sleep 8h a night :)


I put a copy of putty at a short but private url at my own domain so that I can get it over https.


How do you know the public key is correct?


The level of assurance you get with a signing key downloaded over HTTP and one downloaded over HTTPS is roughly equivalent. Sure, HTTPS gives you a degree of protection from MitM attacks, but it won't stop attackers (whether criminals or militaries) from hacking the web server and changing both the software and the signing keys---after all, if one is possible, so is the other.


Clearly we have different concepts of "roughly equivalent" :) One means everyone on your network can trivially serve you trojanized binaries, the other doesn't.


I think hacking a web server is a lot easier than hacking a network connection. Hacking web servers is well within the capabilities of your average vandal, while hacking network links in order to perform a MitM attack requires significant resources (e.g., those of a large criminal syndicate or an intelligence service, but I repeat myself).

Edited to add: ARP-spoofing the right LAN requires spearphishing and APT, which I think also require significant resources.


Sure, against a complete stranger the web server might be more vulnerable, but sometimes the attackers are already in our LANs :)

I was thinking more about employees, or students at universities, or such. I believe I've seen tools that ARP-spoof and then automatically detect downloads of ELF or PE files and trojanize them, all without requiring almost any knowledge from the attacker. I don't know if any of these tools detect Putty and fix its signature too, but it wouldn't be hard to do.


That still allows an attacker to deliver you an older binary than you previously had installed — potentially one with major vulnerabilities.

Signing doesn't prevent downgrade attacks, HTTPS does.


You would also look at the version number when you check the signature...


The signature is automatically verified by the system — when you open the installer, it either shows "unknown developer" or "PuTTY team" in the UAC dialog. Which is easy to verify.

Do you know the version of PuTTY you have installed without checking?


putty.org is owned by a competitor, Bitvise


putty.org links to the official downloads nowadays


If a company can't spare the time of a senior team member to talk to you after some initial vetting they are probably not worth your time. I've been on the other side quite often and properly interviewing is time intense. Preparation, conducting and wrap-up can easily be 4 hours. We only assign a senior member if we think it could be a match and we need to actively persuade the candidate. So unless you really want a position, if you get an inexperienced interview partner just cut your losses and move on. Don't think too much about it and focus on the next one.

Just generally, be bolder with how you select your employer. If they don't want to know you personally, move on. If they are not interested in what you did in previous positions, move on. If they are only interested in skills you built up previously, move on (because they won't want to develop you). Etc...


> So it goes.

Always makes my day :)


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: