Hacker Newsnew | past | comments | ask | show | jobs | submit | pit2's commentslogin

I used the Shipping Forecast as a "self-assessment" when I move to London. When moved there, my English was not the best. I was staying up late at nights, listening BBC4 to improve my listening and I will listen to the shipping forecast every night and don't understand ANYTHING.

That was for the first year, life moves on, and there I was, listening to the Shipping Forecast 3-4 years later. "Ey, I can get now some words and the overall meaning!". I have to say it felt good.

A few more years later, and it was my last night living in the UK (Brexit means Brexit), and I went to listen to it again. Seven years later, since the first time I hear it, I was able to catch everything on the forecast.

For me, the Shipping Forecast will always be something special.


Related in theme but off-topic: When I started med school in 1970, I was all full of myself as a doctor-to-be so I took advantage of the very cheap student rate and subscribed to the New England Journal of Medicine. The first issue arrived: Yikes! I didn't understand a word of it. Fast forward to 1974 when I graduated: reading and understanding the NEJM was effortless, as easy as Sports Illustrated.


That's my favorite part of learning anything. No matter what I pick up, initially the lingo makes no sense. Then over time, words and phrases get associated with meanings and my mental map of the subject gets rid of 'Here Be Dragons'. Felt the same about Computer Science, Accounting, ERP systems, kayaking, AI, Cricut, and cockatiels. No matter what the field, nothing makes sense initially. "Birds clean their crop? What?"

Now I am at the same place of confusion with Go (the game). The more things don't make sense, the more excited I am. From experience, I know most people dread this feeling of not-knowing. But it is my favorite place to be because I know at the end of it, I will have learned something.


I'm a medical student, and I had my wowsers moment when I attended a conference a bit over a year ago and realised that, unlike the previous conference I had attended, I suddenly knew what everybody was on about! The acronyms, shorthands, etc - it really is another language!


In the same vein (no pun intended): when I began my anesthesiology residency, I received a free subscription to the journal Anesthesiology as part of my resident membership in the American Society of Anesthesiologists. The first issue came: frightening! As had been the case years earlier with the NEJM when I started med school, I couldn't understand anything. The table of contents might just as well have been written in Urdu. Flash forward a year: my first scientific publication (a Letter to the Editor) appeared in Anesthesia and Analgesia. Nothing like a little fear to accelerate the learning curve!


Even if he's not charging for the service, I am pretty sure he's getting more consultancy work from these "PR" (notice the quotes) posts. Even the timing on which he releases them makes sense in a way to prevent people from getting too tired of this service.

Not saying is a bad thing but don't assume something is for pure altruism because not many things are.


Have you ever been paid to do work that you really want to happen? Been paid to improve the world in a small, but significant way? It's a lovely feeling.


But what is the value-add of this service?

Complex passwords are quite useful if the server gets hacked and someone walks away with the (salted) password hashes. Against brute-forcing passwords at the login screen of an application they don't add much value, other than making it the user quite hard to remember what the password for this particular site could be...

Theoretically, if you block a user ID after say 5 or so invalid logins, almost any bad password from the Have I been P0wned list will prevent you from being hacked. The chance that you pick exactly that password from the 1-million or so list is quite minimal.

So with that in mind, wouldn't this service be something for website owners that don't know how to properly secure the information they control?


Because chances are, if you are using a password that is in the list, it's because either it's an exceedingly common password (and you really shouldn't be using it) or you've used it before multiple times and are probably the reason it is in the list (because it was breached on another site).

From experience, most attacks we see now are credential stuffing attacks rather than pure brute force attacks using something like Sentry MBA, with a huge number of IP addresses (the last attack we saw was using over 6 million IP addresses). So throttling sign in attempts at the IP level is almost useless as is throttling at the email level, as the attacker can attempt at least 6 million known email/password combinations to see if those accounts exist on your site.

The only real defence against that is all your users using 2 factor, or creating a psuedo 2nd factor (email them if the attempt is from an unrecognised IP).

Edit: Of course the other helpful defence is to ensure your users aren't reusing passwords, which is where Pwned Passwords comes in.


I can attest to this. Credential stuffing was the number 1 reason we decided to add the pwnedpassword validation to our signup flows. We were seeing thousands of IP addresses and hundreds of thousands of requests over a few days. Rate limiting slows it down but doesn’t help all that much. Rate limiting on a specific username will prevent brute forcing but exposes you to DOS. Rate limiting by IP becomes less effective when thousands are involved and most requests end up succeeding.

Disclaimer: work for Kogan who is mentioned in TFA.


> Rate limiting by IP becomes less effective when thousands are involved and most requests end up succeeding.

What do you mean by "end up succeeding"? Most requests successfully authenticated? On the first try? Second try? Tenth try? Hundredth try?

(I'm not trying to doubt the utility of pwnedpassword validation; just hoping you can help me understand the threat you're facing and why IP rate limiting didn't help much. Thanks.)


Perhaps an example will help.

Lets say you have IP throttling/rate limiting. And you have it set to an extremely conservative limit - 1 sign in attempt every hour. This is great for the brute force threat - 24 passwords a day can be attempted by 1 IP. Infeasible for any brute forcing.

But now lets say the attacker has access to a botnet with 6 million unique IP addresses (not theoretical - see my comment above).

Now for each of those 6 million IPs they can try 24 passwords a day - i.e. 144 million attempts a day without ever triggering the throttle.

Bear in mind also that they aren't just trying random passwords for an account - they have a compiled/combined breach list of known account/password combinations from other breaches. So they can attempt 144 million known combinations a day. Without hitting any throttles (this is what the parent above means by "end up succeding").

What percentage of your users reuse passwords and have been exposed to at least one breach? I would suggest it's quite a high value. How long do you think it will take a credential stuffing attack to identify those accounts on your site when they can try 100's of millions of combinations a day?

This is the threat vector.


ISTM the next step would be to rate limit for a given account without regard to IP. Sure that's a potential DOS, but we can wait until that's actually a problem before worrying about it.


They aren’t trying the same account multiple times. Well they may be conincidentally (if the user uses a unique password per site and has been breached from multiple sites so appears in the breach list multiple times with different passwords) but not that frequently. What they are looking for is the intersection of users who reuse passwords and have been exposed by a breach and those users who have created an account on your site reusing the same password. Which is perhaps not surprisingly a relatively large percentage of your users.


From a wrestler to a wolf: thank you. Very helpful.


Thank you, this covered what I was trying to say.


I think what he’s saying is that if the attacker has enough IP addresses at their disposal, they can spread out the attack broadly enough that any IP-based rate limit that would stop a bot would also impact human users. Thus most of the bot attempts slip in under the rate limit.


> Rate limiting on a specific username will prevent brute forcing but exposes you to DOS.

Why?


Not the OP, but I think he's referring to the potential for an automated service spamming thousands (or more) accounts enough to lock them.


You can lock a user out of their account by spamming the server with login attempts.


Yes. In this case the denial of service is against specific customer accounts for the lockout duration, not against the availability of the site.


This would be bad, but what's the motivation? What fabulous prizes await the DOSer of some random account on your service?


Locking users out of their accounts isn’t the goal, it’s just an unfortunate side effect.


If Jimmy uses the same password everywhere, and his password has gotten out in a prior leak, then it's likely that his favorite username is associated with that password.

If he comes to my site and signs up with that password, an "evil person" doesn't need 5 guesses to get into his account - they just need one, because they already have it.

If, however, I check Jimmy's password when he registers, and block him from using it: (1) I keep him from immediately losing control of his account on my service, and (2) I provide Jimmy with the knowledge that his favorite password was leaked and he needs to do something about it.


I can think of a few value-adds for people who practice moderate opsec:

1. If one of your passwords is suddenly rejected, it may be a great moment to refer you to HIBP.

2. Traditional password complexity estimations may be overestimating your passwords complexity, e.g. the pass phrase "My house is blue" is fairly long and will likely be flagged as complex enough. But it's within the realm of a password-phrase aware tool.


Thinking that you have a 0% chance of loosing your hashes is one of the strongest possible indicators that they are on an open filesystem being served by Apache.


It looks like the witch-hunting is about to start.


It's about time.


That is... wow... it totally deserves the "nightmare" tag. Thanks for sharing!


A tad too late to be sorry, Mark.


Not a code to deploy but on the address bar of an old kiosk browser. An ugly JavaScript script to escape the computer lockdown and access the filesystem. Always nice to debug a one huge line of JavaScript that outputs HTML/ActiveX.


My parents used to leave me near the computers in shopping malls when I was little. Shopping bored me to death, but I liked to fiddle with all the computers on the display. Trying to bypass some locks, just for the fun of it (and sometimes even succeeding! :)) and typing JavaScript into IE's address bar to display some fun stuff was always my main occupation :D Plus I didn't have to go with parents around the whole shop and they knew where to expect me.

I also vaguely remember escaping some "internet cafe" kiosk at some hotel during one of the abroad school trips. The kiosk had "broken" sticker on it and seemed actually broken, but some functionality still worked and after escaping the kiosk UI I was able to actually fix it (as we actually wanted to use it) - don't remember what was it though :( Some technician was probably either grateful for a null job afterwards, or lost an order due to me ;)


I am seeing a trend in HN lately of linking, supposedly, interesting Wikipedia articles. Is this done for internet points? I will assume it is.


You already failed the exam if you clicked the link from your Facebook-signed/Google-signed browser.


You failed the test by knowing what sorts of information your browser shares and making a decision based on that information?


Here you have +100 more: https://umaar.com/dev-tips/


Does anyone know how this can be exported/used/translated to work with Inkscape?


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

Search: