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

It may be useful for websites to make these logs public. The logs would show the exact time, the IP and the specific abuse.

In my experience, a lot of 'threat intelligence' data has a mysterious origin and is marginally useful. Yes, Tor exit nodes do bad things. Thank you, we sort of already knew that.

But I'm not sure that's really beneficial either. It would be interesting to observe trends (such as log4j) and we could see first hand how Tor exit nodes are used for abuse and maybe collect a large list of 'known bad' IPs.

Also, when we say an IP is bad (because it was observed doing a bad thing), how long do we keep it on the naughty list? 24 hours? More? Less? It may have been dynamically assigned and later some 'good' person will come along and want to use it to browse the web. If the IP is still on the bad list, that person will potentially be blocked by over zealous 'security professionals' who don't understand or don't care.

What other uses could be made of this type of log data?


>It would be interesting to observe trends (such as log4j) and we could see first hand how Tor exit nodes are used for abuse and maybe collect a large list of 'known bad' IPs.

> Also, when we say an IP is bad (because it was observed doing a bad thing), how long do we keep it on the naughty list? 24 hours? More? Less?

Look at GreyNoise's public feed - they provide historical data about IP's including the attacks they send. Most of the IP's end up being some kind of DC IP, not residential. Eg - https://viz.greynoise.io/ip/45.148.10.193

I agree with the questions you've raised, and think that vendors like Greynoise are helping sort out those issues.


Abuse IP DB [1] does something like that, they provide an API to report and check IPs.

[1] https://www.abuseipdb.com/


I agree 100% with this statement (and with the article in general):

    “Basic hygiene” is arguably better than any of these bolt-on option, including things like:

    * Knowing what dependencies are present
    * Being purposeful about what goes into your software
    * Choosing a tech stack you can understand and maintain
    * Choosing tools that are appropriate for the software you are building


It's true in security in general, that really sticking to basic hygiene would mitigate a lot of more advanced threats. We haven't had much success over the decades though in getting people to stick to it.


If it earns 20 million + each year, I'd leave it alone.


Off topic... What's the best way to easily recycle these batteries? I normally disassemble my old phones and securely dispose of the chips (for my privacy), but the batteries are glued in with a strong adhesive. Just trying to remove them can start a fire. I think most people just throw the old phones in the trash, but I don't like to do that. It's bad for the environment and potentially dangerous to trash workers.

It seems that phone manufacturers should make the batteries easy to remove, replace and recycle. Not sure why they do not do this.

Home Depot has drop offs for old batteries, but last time I was there they told me they were for power tool batteries only now.


My local Best Buy takes old electronics for free. Haven't found any other place. The local dump charges per pound. I'm sure most people just throw it all in the trash. Not a good situation we're in - so many things are labeled as requiring special disposal, but there's this sort of wink wink nudge nudge that the labels will be ignored.


Factory reset them then sell them on Facebook or local classifieds.

People will pay good coin for a used phone in good nick. Or a used anything, really. I personally just paid around $50 USD for an iPad Mini 2, and during the pandemic I dropped around $150 USD on a 2015 MacBook with a broken screen.

Some of the stuff people put into hard rubbish blows my mind.


Even if the facilities don't exist we can store them in remote areas right. Maybe put each in a fireproof bag.

I'm not an expert but isn't one huge advantage of batteries is they are mostly solid so unlike c02 which disperses in the air we can store them in one place that doesn't cause harm.

For EV batteries couldn't we just put them in a fire proof, water proof bag or container until the battery is ready for processing


My local waste transfer station has a dropoff for lithium batteries, presumably they send them off to be recycled but who knows.


If you drain the battery to zero charge first I think it's pretty safe


I take mine to the local dump. They have an electronics recycling drop off, which is free.


My city has a recycling center for household products, but it requires the use of a motor vehicle. I have been unsuccessful in using taxi or ride-sharing services to drop off items. Unfortunately, the inflexible vehicle requirement is a deal breaker for me and many of my neighbors.


> it requires the use of a motor vehicle

as in "it's miles away from the next bus stop, so walking is impractical", or as in "if you don't show up in a motor vehicle, we don't let you in"?


Some recycling centres in my country don't allow entry on foot. They'll allow entry on a motorbike, don't know about a bicycle.

I speculate it's because they often have hours-long queues, and people in cars might decide to park and walk past the queue, if it was allowed, which could get chaotic.

Or perhaps the rules were just written by someone who hadn't considered non-car-owners.


Probably out of town. And even in town, it's one thing to walk to it with a dead phone and another to walk with a dead TV :)


In Norway most supermarkets have a box for used batteries, broken light bulbs, fluorescent tubes as well as a reverse vending machine for drinks cans and bottles.

Shops that sell electrical goods (computers, audiovisual, cookers, etc.) have to be willing to accept electrical goods for recycling even if they don't sell that specific model or even brand. So a lot more people are within a reasonable distance of a place to recycle quite a few things.

Perhaps stores elsewhere could do the same.


A lot of them also do curbside recycling once or twice a year for electronics and large appliances. Mine does, but I don't like batteries sitting around where I'll forget about them and my local dump is right across the street from a Home Depot, so I drop them off when I usually go to Home Depot.


Also, I think Wallmart and Sam's club have recycling collection points.


Just consider the whole phone to be the 'battery case'.


I dropped off my last lithium laptop battery at Best Buy.



The design flaws of these systems are the fact that they are terrible at changing passwords, dealing with the arbitrary password requirements of many sites, and dealing with the fact that many sites require the storage of additional secrets for practical use that cannot be generated. (eg. secondary passwords or pin codes for privileged operations within the application, mandatory security questions, etc)


KeePassXC supports all of that?


I believe the comment you're replying to is referring to the weaknesses of deterministic password generators.


One example I like to use (when talking about entropy):

A four digit numeric PIN (that we know) has 0 bits of entropy. There is no uncertainty about what the PIN actually is. A randomly selected one (that we do not know) has just over 13 bits.

print(math.log(10)/math.log(2)*4)

13.28771237954945

The more entropy, the more uncertain we are.

However, humans are not random. We use the year we were born, some keyboard sequence or some other predictable number as our PIN. We don't know exactly how much entropy these PINS have (there is some degree of uncertainty), but we do know they are significantly less than 13 bits.


I wrote a blog post [1] with an interactive widget where you can provide an encoding for a random decimal digit and see how close you can get to the theoretical log₂(10) ≈ 3.32 bits.

[1]: https://blog.kardas.org/post/entropy/ (Average Code Length section)


Here's a riddle.

If using my birthday reduces the entropy of my PIN, what does it do to its entropy if I happen to have the same birthday as one of the most famous people in the world? Does it matter if I am aware or not? Does it matter what they use for their PIN?

For the sake of argument, I'm thinking month and day, not year.


The important thing is that your PIN has zero entropy, regardless of its value. Entropy is a property of distributions, not individual values. You may be thinking of the probability (or information content) your PIN is assigned when looking at the overally distributions of PIN, in which case it probably does matter how popular your birthday is (and whether it also matches common patterns people use for PINs). This does feed into the calculation of entropy for the distribution but then it ceases to tell you anything about your PIN specifically. It also only makes sense when you are looking at it relative to the distribution, so it matters how you specify the PINs you are comparing it to.

The 'information content' of a given outcome is the logarithm of the inverse of its probability (i.e. more unlikely events give you more information), and the entropy of a distribution is the expected value of this information content.


That is not a riddle just a question how to handle information on the distribution of passwords in the population. So you get the same answer as if it were four alphabetic characters and your choice is "soup".


I still see them. They come and go, but are always present at some level.

    2022-08-29T17:35:12.617Z [DEBUG] sshlog gen 113.61.219.237 admin admin SSH-2.0-HELLOWORLD
    2022-08-29T17:48:17.879Z [DEBUG] sshlog gen 218.92.0.190 root poohbear SSH-2.0-PUTTY
    2022-08-29T17:48:18.041Z [DEBUG] sshlog gen 218.92.0.190 root p@ssw0rd3 SSH-2.0-PUTTY
    2022-08-29T17:48:18.2Z [DEBUG] sshlog gen 218.92.0.190 root p@ssword! SSH-2.0-PUTTY
    2022-08-29T17:50:13.507Z [DEBUG] sshlog gen 185.191.205.92 hl hl SSH-2.0-libssh-0.6.3
    2022-08-29T17:52:57.28Z [DEBUG] sshlog gen 138.68.91.192 victoria abc123 SSH-2.0-libssh-0.6.3


May I ask how to configure the sshd to generate logs like yours? I searched for it and could not find much information.


It's called sshlog. It's a patch that logs username/password.

https://github.com/62726164/sshlog


Thank you very much for the kind reply. I will try it out on one of my vps servers. Looking to have some fun when performing analysis afterwards. Thanks!


I agree. It's also an ISO standard that IMPO, will be in use for the next 50 to 100 years. Modern C++ is very safe and very fast and very mature.


I would also recommend Go for web developers who want both speed and memory safety. It works well and is hard to beat, but I haven't seen any Go web framework that comes close to Ruby on Rails. If anything like that ever does come along, I think it will be very popular.

I like Ruby a lot. I'm not knocking it. It's probably the most enjoyable language I've ever used.


I agree with your suggestion. I think Post Offices, DMVs, and large reputable retailers (Walmart, Target, Cellular Phone companies, etc.) could verify our identities for a small fee and help us reset our social accounts when needed. I arrived at the same conclusion and wrote a blog post about it a few years ago:

https://www.go350.com/posts/now-they-have-2fa-problems/


Aren't half of those things you listed (Walmart, Target, Cellular Phone companies, etc.) also exactly how people get unauthorized access?

You convince the employee to port "your" number and they do so and then you reset that accounts password?

https://www.wptv.com/money/consumer/phone-porting-leads-to-s...


Make it a choice. It sure sounds like the patrons of this library would opt in.


Well, good old Yahoo Mail does that. Time and time again it tries to convince me to set up 2FA (for an account I use rarely), and time and time again I say "No" - and that's it! The library patrons would probably be very happy with that...


I distinctly remember lynching from HN security crowd when SIM cards were being unlocked and moved to new people from "trusted companies" like Verizon and AT&T.

HN demanded for such security holes to be disabled and prevented - what changed since then?


What changes is that there are different needs from different segments of the world, and we have reached a problem (authentication in general) that is truly impossible to solve with our current toolset.

For me, the larger threat is that someone impersonates me and takes everything I have. If I lost my email, it would be a nightmare but I could work around significant portions of the system. For my cousin, the larger threat is losing her email, as she has no significant assets to steal but could run into every problem in the email.

There are likely people in the middle as well, and other threat vectors. (For example: caregivers committing fraud, dementia, state actors, and 20 other we could brainstorm pretty quickly.) Perhaps the right answer is that we need 20 different services that can segment. Perhaps the problem is that some sectors aren't profitable: maybe we need a grant for emails for poor people with a circle of trust.

I don't have answers. Maybe we need a collection of people to think deeply about this problem.


What changed is that we're starting to learn about the breadth of needs by people with different lives and opportunity sets, and feel at least a desire to talk through potential solutions for a subset of people who opt into it.

If the worst thing that people could commit in this discussion is hypocrisy, I'm sure they're willing to step over that line.


This is widely implemented and used in Germany: https://www.deutschepost.de/en/p/postident.html

It's a lot easier to implement reliably due to the requirement for everyone to have ID cards though (and the ID cards carry your residence address).


Walmart may be a reputable retailer, but it is utterly disreputable in being a reliable arbiter of identity. It doesn't train its employees well, its employees are often not the brightest bolts an the box, and those that are often don't give a shit.

As for post offices, they aren't eligible because half the government is actively trying to kill them.


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

Search: