Jump to content

Site questions, comments, and suggestions


Guest

Recommended Posts

17 hours ago, CPU said:

I did nothing. And because also Ashal is offline, I am not sure it was something on the site. But probably on your end.

It's the same for me though (B&W wrong sized smileys), and I just emptied the cache. Also, there are still strange bullets on the create blog/entry on the top of the main page of the blogs section. But all of that is secondary and can wait.

 

Also since a few versions, only images viewed are loaded. As unusual as that change might have seemed, I think it's a rather good thing, as it avoids loading entire pages while readers are interested in a few posts, and also helps when users aren't experienced in image compressions, as they are loaded spoiler by spoiler (which is wayy easier to handle for average to small connections).

My thanks to Ashal for bringing stability back. ?

Link to comment
5 hours ago, RitualClarity said:

Perhaps a special log in for those using Proxies and / or  Tor et

I don't have any trouble logging in using Nord VPN, even when I'm using a connection in a different country.

Link to comment
Quote
12 hours ago, CPU said:

I did nothing. And because also Ashal is offline, I am not sure it was something on the site. But probably on your end.

 

I spoke too soon. My emojis are B&W again and the ones I posted yesterday now look B&W on the site (like in your quote of my last post).

Link to comment

I also think the captcha is not ideal...there are more better ones, for best with numbers-entering four numbers and done....this picture-nonsence is failing (not exactly working) and the time behind the screen for that pass becomes in sum to fill over a year maybe more than one hour time for stupid log-in-puzzels. I´d never let such a stuff onto my website.

Link to comment
3 hours ago, t.ara said:

I also think the captcha is not ideal...there are more better ones, for best with numbers-entering four numbers and done....this picture-nonsence is failing (not exactly working) and the time behind the screen for that pass becomes in sum to fill over a year maybe more than one hour time for stupid log-in-puzzels. I´d never let such a stuff onto my website.

That is the reason, why I do not log out, or make my browser cache not empty!
I am an old man and with such captcha I can not access anymore, I can not handle this! 

 

edit: Orion (DAI) has this kind of captcha too, my password has been blocked for some reason.
to sign up again come this captcha and I have absolute problems with it and therefore I can not play DAI anymore! :classic_sad:

Link to comment
8 minutes ago, winny257 said:

That is the reason, why I do not log out, or make my browser cache not empty!
I am an old man and with such captcha I can not access anymore, I can not handle this! 

Hi winny! , I´m pretty sure that the LL team will think about that again...pretty sure:-)

Link to comment
4 minutes ago, RitualClarity said:

Why does sites need capta when they have a proper log in and password? They know who you are. Only reason I can see is if you are coming from a different Ip address to be sure you are .. well you.

 

 

Because we had many attempts to hack users by brute forcing passwords.

A captcha makes it impossible to achieve.

In case you don't like the captcha, you can always turn on the double authentication (like I do), in this case you will need to authenticate again (with your samrtphone) only if you use a brand new browser or computer.

Link to comment

Just to clear it out as it seems some people think only those who have to relog are getting captchas, but I am getting them while never logging out (cookie is never deleted either as it's a first party cookie).

Link to comment
6 hours ago, CPU said:

Because we had many attempts to hack users by brute forcing passwords.

A captcha makes it impossible to achieve.

In case you don't like the captcha, you can always turn on the double authentication (like I do), in this case you will need to authenticate again (with your samrtphone) only if you use a brand new browser or computer.

Didn't know about the brute forcing of passwords...
mine is INSANE... lol  (used something to help make the password so it is as random as possible and reasonanblly large... = pain in the ass to punch in ;))

Link to comment
5 hours ago, Hawk9969 said:

Just to clear it out as it seems some people think only those who have to relog are getting captchas, but I am getting them while never logging out (cookie is never deleted either as it's a first party cookie).

That isn't correct at least not on my end.. I haven't had to do the captias after logging in (and not out) on my computer I use for this.

Link to comment
11 hours ago, CPU said:

Because we had many attempts to hack users by brute forcing passwords.

A captcha makes it impossible to achieve.

In case you don't like the captcha, you can always turn on the double authentication (like I do), in this case you will need to authenticate again (with your samrtphone) only if you use a brand new browser or computer.

 

Bullshit.  Criminals don't brute force webpages.  They brute force the stolen databases offline that they steal during DDoS attacks.  If you're seeing actual users fail their passwords it's because of other reasons.  Like using privacy badger to completely block google's tracker gstatic. 

 

So no, recaptcha doesn't make it impossible to brute force passwords.   It just ads another layer of nonsense legitimate users have to put up with.

 

Your solution just ads the user's phone number to the password data base making it more attractive to the people going after data bases.

Link to comment
13 hours ago, CPU said:

Because we had many attempts to hack users by brute forcing passwords.

A captcha makes it impossible to achieve.

In case you don't like the captcha, you can always turn on the double authentication (like I do), in this case you will need to authenticate again (with your samrtphone) only if you use a brand new browser or computer.

 

GA is not a perfect solution. While it solves the problem of someone logging in with a brute-forced login and password, it still doesn't solve the performance issue - those login attempts still drag the site down by constantly hitting the database. 

 

The solution I use on commercial sites is a bit of a more tricky one. The idea is to give the user an encoded Javascript blob which acts as a signer for the requests to the site. When user visits the login page, the script gets downloaded and then it requests an encrypted ticket from the server.  The server forms the ticket based on visitor's User Agent, IP and the request time, so they are all unique, the ticket gets encrypted and sent to the user. The JS part now decodes the ticket. and then encrypts it again with its own public key. And then sends it back to the server. The server checks for the validity (it needs the private key for that) and if it's okay - it processes the request.  If the returned ticket is invalid - the request never hits the database.

 

While it's not 100% hack-proof in theory (the client does get everything it needs, after all) it still proven to be really successful in practice. The best part of it is that the guardian can be implemented even w/o changing any code of the site itself at all, even as the HTTP server extension. I wrote one in the Go language. Since I do retain the full copyright, I could share it with you guys - provided there is someone who can tweak the Go code to your needs, it has probably more than you need - I mean it's a full-blown custom HTTP server written in Go. and there is also the JavaScript part, which again needs to be tailored to your needs and encrypted somehow (there are enough free on-line services for that). If you're interested, just drop me a note, I won't charge anything, it's one of my favorite sites and I would like to contribute. 

Link to comment
20 minutes ago, MadMansGun said:

actually some DDoS attacks work by targeting the login screen, it's a "2 birds 1 stone" attack method to both take down the site and get it's user passwords at the same time.

This is *not* a DDoS attack by the very definition of it. DDoS is a distributed denial of service attack. You can't brute-force a site you've brought down completely by DDoS attack.  The purposes of DDoS and brute-force attacks are mutually exclusive ones. You can't kill 2 birds with one stone here.

 

It's just that some sites - a lot of them, in fact - can't handle a massive brute-force attack. 

Link to comment
10 hours ago, RitualClarity said:

That isn't correct at least not on my end.. I haven't had to do the captias after logging in (and not out) on my computer I use for this.

Just because it doesn't happen on your end, doesn't mean it doesn't happen at all. Why would I lie?

 

I am from Brazil (not sure if that plays a role) and my browser and its extensions are privacy oriented, although cookies are whitelisted in here as long as they are first-party ones.

I do not need to relog, but I do often need to input captchas.

Link to comment
50 minutes ago, Hawk9969 said:

I am from Brazil (not sure if that plays a role) and my browser and its extensions are privacy oriented, although cookies are whitelisted in here as long as they are first-party ones.

 

This may be the problem. The CDN may use its own cookies to filter out bots, and those come out as 3rd party ones. As you lose them, the CDN may once again send you for a cookie check.

 

Remove all cookies from your browser to start from scratch, log in to the site and then look at all cookies you've got. If you have some originating the CDN, Cloudflare, whitelist them as well. This may stop those captchas from bothering you all the time.

Link to comment
35 minutes ago, phillout said:

This may be the problem. The CDN may use its own cookies to filter out bots, and those come out as 3rd party ones. As you lose them, the CDN may once again send you for a cookie check.

 

Remove all cookies from your browser to start from scratch, log in to the site and then look at all cookies you've got. If you have some originating the CDN, Cloudflare, whitelist them as well. This may stop those captchas from bothering you all the time.

It's not all the time though, it's arbitrary. Like now, I didn't need to input them.

Also, I don't lose 3rd party cookies, they are not stored at all (including the browser's heap).

 

I assume they just whitelist my IP (maybe a combination of IP and User Agent) after inputting the captcha for a randomized time.

Link to comment
9 minutes ago, MadMansGun said:

hitting a site with so many login requests that it kills it in the process counts as a DDoS attack.

Then if your site gets a traffic spike coming from some popular hub to the point it can't handle it anymore (see Slashdot effect) - does it count as DDoS attack as well?  Hey, it stops your site from functioning. I've seen crappy sites breaking down at 1-2 millions of visitors per day, for them any surge in traffic would be a "DDoS". 

 

There is quite a strict and easy to understand definition what DoS and DDoS attacks are. The purpose of BF attack is to harvest passwords, if you just block the bots from the login page (which is actually pretty easy), you are safe. You can't handle a DDoS attack that easily - just by blocking a single page. Go ahead, do some reading on what a real DDoS attack looks like. Unless you run an online casino or some illegal drug site, you're unlikely to ever see one of those. 

Link to comment
12 hours ago, phillout said:
Spoiler

GA is not a perfect solution. While it solves the problem of someone logging in with a brute-forced login and password, it still doesn't solve the performance issue - those login attempts still drag the site down by constantly hitting the database. 

 

The solution I use on commercial sites is a bit of a more tricky one. The idea is to give the user an encoded Javascript blob which acts as a signer for the requests to the site. When user visits the login page, the script gets downloaded and then it requests an encrypted ticket from the server.  The server forms the ticket based on visitor's User Agent, IP and the request time, so they are all unique, the ticket gets encrypted and sent to the user. The JS part now decodes the ticket. and then encrypts it again with its own public key. And then sends it back to the server. The server checks for the validity (it needs the private key for that) and if it's okay - it processes the request.  If the returned ticket is invalid - the request never hits the database.

 

While it's not 100% hack-proof in theory (the client does get everything it needs, after all) it still proven to be really successful in practice. The best part of it is that the guardian can be implemented even w/o changing any code of the site itself at all, even as the HTTP server extension. I wrote one in the Go language. Since I do retain the full copyright, I could share it with you guys - provided there is someone who can tweak the Go code to your needs, it has probably more than you need - I mean it's a full-blown custom HTTP server written in Go. and there is also the JavaScript part, which again needs to be tailored to your needs and encrypted somehow (there are enough free on-line services for that). If you're interested, just drop me a note, I won't charge anything, it's one of my favorite sites and I would like to contribute. 

 

Are you crazy, I already have problems with captchas!
if something like that comes, then I can me shoot dead!

I give myself the Bullet :classic_laugh:

spacer.png

Link to comment

Bottom line, lots of site requests have been made to the login page. And although most have now been blocked... I value you're password protection over your potential hate of filling a captcha on occasion. And no; not interested in hearing how Google is the apparent devil now. You have bigger, solvable, issues you need to deal with first if this is a problem for you.

 

If you think Google is selling your info, you don't understand Googles business to begin with. A good business obviously doesn't sell it's trade info (fyi, in case it needs to be said... LL has never once sold any data, I wouldn't even know how to do so?)

 

I have ZERO sympathy on this if TOR is your main browser. You should've known what you were getting into, or you shouldn't have been using TOR to begin with. 

Link to comment
Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. For more information, see our Privacy Policy & Terms of Use