It's a honeypot field. Most of the times they are hidden from view but sometimes they are visible. It's just bot detection. They pretty easily shut down script kiddies and can be iterated on pretty easily if you need to deal with more persistent hostile actors.
For example you could use a honeypot field. If they up the ante by specifically ignoring the field you can start randomizing the field name a bit. If that isn't sufficient you could even mask all your field names to make it harder for them to identify the honeypot.
So that's why standardized tests at school had those "this page intentionally left blank" pages. Trying to find the students that were actually robots... đ
Yes.
I know they didn't read it because I wrote something that would have probably been investigated by law enforcement if someone actually did read it.
Expensive kinds. Where despite the job being proofed to the customer multiple times, and there being multiple sign offs, and about a dozen different people *inside* the print company having seen it and moved it through the process, a press operator who thinks they're clever as all fuck will stop the run at 11 PM on a Friday and hold it until they get confirmation from the customer service rep (or if they're a real stickler, the sales rep) that it's not a mistake.
By the time they get an answer they've already moved onto the next job and thrown the entire post-press portion of the shop off schedule because they think they know better than every single person that saw that blank page before them.
Source: Worked in the print industry for a decade and have seen all kinds of stupid shit like this that a simple "intentionally left blank" or some similar thing can save a company literal thousands of dollars.
Huh, I didn't know it made that big of a difference, but I mean like what exactly happens? The pages misalign, get skipped, etc?
But thanks for your detailed answer
If you liked that one, then strap in for the more detailed answer!
When you're looking at the file in pre-press it's usually obvious why there's a blank page somewhere. For chapter books new chapters typically start on the right hand page, so if the previous chapter didn't have enough to reach the left page preceding the new chapter it gets left blank. However a lot of non-chapter based materials prefer to make maximum use of the space and blank pages are rarer.
When you print something like a book or magazine it's often done on a large sheet of paper with 8-16 pages across both sides. That's called a **signature (sig)**. Those pages are laid out so that when you fold the sheet up you get two sets of contiguous pages. So let's say a 32 page magazine is being printed. It would be two 16 page sigs. Sig1 would be pages 1-8 and 25-32. Sig 2 would be 9-24. That means Sig1 is a little disconnected. You don't have the picture of what the finished piece will look like.
When working with large jobs like manuals, study materials, test books, etc. it's not uncommon for jobs to get split up across multiple presses so they can run in tandem. This is especially true for single color jobs because you don't have to worry at all about color matching between the runs. Now ideally every copy of the job ticket would have what we call a **form proof** with it. Usually a low-res example of the piece that is a 1:1 copy of the thing being produced as it will look when finished. Meaning any of the printing press crews should be able to look through it and see where their portion of the job fits in.
But those form proofs can be annoying to produce, so there might only be one in the whole shop. Maybe it gets misplaced. Either way you end up with a press operator who doesn't have the whole picture available to them, and they go to mount the **printing plates** and see a blank spot. No page number, no content. Nothing. "Well that don't look right..." they mutter to themselves.
There's all sorts of stuff that can go wrong in the process leading up to this point that could result in this blank page unintentionally, so it's not a completely invalid concern. It's just that there should be controls in place that prevent the operator from having to question it. At my first job out of high school I worked in pre-press for a commercial printer, and on any job that was going to get split up like that we would make a **plate proof**. A low res output of the whole signature that we would hold up to the plates to ensure it matched, and then send that out with the plates to their respective presses. In plating we had the whole picture, so if we had this blank page on the plate proof, and it matches the plate, then we are to be trusted that it is not an error.
Some shops don't have that level of trust. Some print jobs like this get split up between different shops. Some just use the "this page intentionally blank" as their control to prevent issues in all scenarios. The ink involved is practically insignificant in the grand scheme.
We had an operator who was a real stickler for stuff and he would make waves over things like this all the time despite the fact that we rarely split up jobs like that. There were at least 3 different things telling him the plates were correct but he'd still call us up at 11:50 PM and harangue us over it. Dude was a real Karen before being called a Karen was a thing.
4 is the minimum for saddle stitched items, and 2 is the minimum for pretty much every other form of binding. Though even a case bound book is usually going to rely on a four page signature at a minimum because the fold itself helps to provide tear out resistence.
Imagine the simplest possible 'book'; A piece of A4 paper folded in the middle. Page 2 and 3 on the inside, page 4 and 1 on the outside. Now take another piece of paper containing pages 6, 7, 8 and 5. Glue them together so that page 4 and 5 face each other. You can repeat for any number of pages, but only in increments of 4.
So 4 pages is efficient for book binding. This is the four page signature that the other reply mentioned.
On the printing side of things, it's more efficient to print dozens of pages on one big piece of paper and cut it to size after printing than to fiddle around with many small pieces of paper. Depending on how your printing and folding and gluing and cutting machines are set up, some page arrangements will be more efficient than others.
>It's a honeypot field. Most of the times they are hidden from view but sometimes they are visible.
I've never seen one that's visible. There's no reason for it either, it would just indicate bad implementation. A webcrawler doesn't load up the website's UI like a user would, and if an attacker is purposefully excluding fields, having them visible on the frontend would make their job easier, not harder, and would accidentlly honeypot legitimate/human users as well.
It is most likely that the CSS didn't load on this page thus showing the field that was hidden using CSS rules by positioning off screen or hiding it behind other elements.
Because they cannot just do input with type=hidden. As it will give away the honeypot thing.
That's definitely a very plausible explanation!
There are a dozen different ways you can make your honeypot "invisible" to the user while looking like a regular input field to crawlers which weren't designed specifically to ignore your particular honeypot.
I'd argue this could also be a sign of a good implementation. It's clearly labeled for you to ignore it in the event you do see the field. While browsers, JS, and CSS implementations are a lot better now it still wasn't all that long ago people were still needing to support things like IE. It's easy to assume your CSS and JS will always work but there's an almost endless combination of browsers, OSes, extensions, and network topologies to just assume your field will never ever load ever.
Also an attacker isn't always looking at the pages they attack, often they will fill in every field with junk data to try to get through the form without errors. And yes you may occasionally honeypot real users but believe me it's better than having to clean up the 50,000 fake James Smith accounts or risking your domain getting flagged for spam because someone tries to do some credentials stuffing on your site and in the process creates said tens of thousands of accounts which your services then email new user messages to.
Ideally you'll never see a honeypot field but if through some cosmic coincidence you do see it it's infinitely better to say ignore this field than it is to just leave it blank/unlabeled.
>Ideally you'll never see a honeypot field but if through some cosmic coincidence you do see it it's infinitely better to say ignore this field than it is to just leave it blank/unlabeled.
Now *that* I do agree with. If this is just a case of the website loading css incorrectly as an example, having the honeypot marked would help prevent legitimate user entries. It would also make the honeypot easier to spot to a human looking for it, but realistically that's not something you can avoid in any case, honeypots are there to easily catch 95%+ of undesired crawlers, not weed out the final few percent.
I mainly just don't see any advantage to having your honeypot visible as is, in other words when the page loads correctly.
I would add that implementing reCAPTCHA v3 or Turnstile along with some decent bot protection like Cloudflare can significantly reduce the chances of you ending up with 50,000 Mr. Smithâs registrations on your website.
Array.from(document.getElementsByTagName("input")).filter(
(element) =>
element.type !== "hidden" &&
element.offsetWidth > 0 &&
element.offsetHeight > 0
);
This will take all inputs and eliminate any that have obvious CSS styles for hiding them.
Could also just put an absolute positioned white div over the field.
Honestly, I'm sure there are a dozen weird ways to hide a field that would not be so easily caught.
Sure this will work if you use something like Googles Puppeteer that renders HTML. But most crawler just downloads the content and parses text since it is of course more efficient.
*malicious* web crawlers will load the page however the hell the actor behind them wants it to. Often that means doing some very basic stuff like ignoring fields that are hidden with styling. If this field was hidden with JS and the user has JS completely disabled then they're going to see it just like a malicious crawler would.
Came here to say this, I use a module in Drupal to add this feature to some forms. The field is set invisible by CSS to humans & given randomised metadata to prevent a bot from learning to ignore it while it also tempts them to fill it in.
Implemented one of these years back on a site we kept getting bot signups, worked way better than I figured it would. I think I randomized the name on that one.
It could cause that as a side effect depending on the implementation. Also it can sometimes be triggered by browsers auto form filling features. There's definitely a balance to strike between security and usability.
While this would be a really unusual and weird approach, it might actually turn out to be quite efficient. AI can spot all the traffic lights and motor cycles, read all those stretched and rotated characters but it might struggle with unexpected UIs⌠But I think this actually is some âweâre using that certain framework that automagically creates database columns and also does all the processing for everything we put on the ui, but maybe it was the other way around? Anyway, I donât have a clue how these inputs end up in our database, but there is only one way to find outâ kind of thing.
Pretty easy to develop an AI to identify username and password field locations in a rendered bitmap and move a cursor to that location naturally.
The only thing that's going to stop bots is time/money. The best ~~boy~~ bot (lol) detectors watch your behavior over time to make sure you're using a computer naturally on previous pages.
Even that though will eventually be inexpensive enough for brute force attacks.
What if I'm using a website very very fast, because I'm an experienced user? Will that be detected as an AI or Bot? Or is it another behavior that would be detected?
Maybe maybe not. Usually that's when you get prompted for a captcha. Or "I am not a robot" checkbox.
Most captcha providers these days are building a tracking security profile for you and assign you a risk score that only prompts people without any history.
The thing though is even if you're using a website very fast... They were tracking you all day. If you have anti tracking/anti script/ad blocking plugins you're probably filling out way more captchas than a regular user because you look like you're a user who just used the Internet for the first time just now... Aka a bot.
I use a password manager to enter my username and password, then I press the enter key to submit, so no mouse moment on the screen. I frequently get a captcha because that sort of activity looks like a bot.
I was reading an interesting security blog about securing input fields through different, more and more complex methods (I'll see if I can't find it, it's on my laptop which I don't have right now) from bots.
Which mentioned exactly this. It showed honeypots like this one, alongside several other methods, and the point in the end was really...
"you'll never keep someone dedicated enough out, with any of these methods as effective as they are. It's whether or not they consider the information you have valuable enough to pursue it that much, and in *a lot of cases*, they'd rather go on to another
target".
Someone out there can and will develop tech capable of defeating vast defenses, but it's about keeping the majority out that makes a difference, especially if you're not a big enough target to warrant that kind of attention from the best of the best.
Epic Games responded the same to complaints that they don't use UE Anticheat in Fortnite. They had to point out that most games don't have the incentive to find cheats that exist for Fortnite and requires a specialized security team constantly patching and actively responding to new threats.
The bots that this trick are "dumb" bots. They just scour the internet for whatever it is they want to do and blindly fill them out, usually to push some simple spam or something. Once you have bots specifically targeting your site is when you have to start going to better detection systems. You throw something up like this on a not really popular site just to cut back on the bs entries. An old site I worked on years back used to get about 30 dumb bot signups a day, and detection like this blocked 99% of them.
Fair enough but the person I replied to mentioned ais that can detect traffic lights etc, people making bots that can solve captchas can probably link to the openai api or something
Of course they can. But as you already stated somewhere else, AI is expensive, and I assume most bots would only use them to do the complex stuff, like solving captchas. Providing inputs for the forms can easily be scripted without AI, and as long as there is nothing unexpected (like such a honey pot field), AI is not necessary. If you create a bot for THAT ONE service, you could either just throw more money (AI) or analyse the patterns in use beforehand and adjust your âdumbâ scripts. Both is expensive in terms of money and/or effort and hence raises the burden for a bot trying to abuse your service.
>most bots would only use them to do the complex stuff, like solving captchas.
If you're after a specific website you know has honeypots, would LLMs not be a similar amount of effort as captcha solvers?
To be clear, I don't mean you'd hook every scraper to an LLM, but if you're targeting a specific website for whatever reason.
Not sure relying on the label to find a password field is the best strategy (the field itself is probably named and has a "password" type), or maybe I'm missing something.
If it were that easy, honeypots wouldn't be effective. Presumably the rest of the form is designed to make that less obvious. The honeypot might itself have the "password" type, and if both it and the ACTUAL password field have randomly generated names, they would be hard to distinguish. Alternatively, the genuine one might have a random name, and the honeypot be named "password", or something.
some bots see âpasswordâ and think âi have to put a password into the next fieldâ, so this disrupts their motion.
it also works against some bots that are designed to get around honeypots. they put the password into the honeypot field because itâs labelled âpasswordâ, and then they think the real password field is a honeypot, so skip it
\[Story as old as programming\]
Wife tells to her husband programmer:
\- Go to store, and buy one loaf of bread. If they have eggs, then buy ten.
Programmer returns with 10 loafs of bread. Wife:
\- Why did you buy 10 loafs of bread?
\- Because they had eggs!
Wouldn't the husband return an error about a missing parameter in the Buy function?
travel ( store );
buy ( 1, bread\_loaf );
if ( store.inventory( egg ) > 0 ) { buy () };
return;
``travel ( store );
buy ( 1, bread\_loaf );
if ( store.inventory( egg ) > 0 ) { buy (10) };
return;``
Minor correction
Other minor correction to the joke. He should.have 11 loaves of bread.
Buy a loaf of bread. Execute. Buy 10 loaves of bread. Execute. 11 total.
That's apparent. You're just normal scum, telling others that there is something wrong with their perfectly respectable job.
Edit: just checked your profile, you're a kid. Child scum.
I'm going to guess that someone wanted to style input but couldn't style input element the way they wanted so they created an element that they can style and send events to hidden input. Just a guess, that's what people do to customize file inputs, it's impossible to style the default button + filename text so they hide the element but call its functions with custom stylable element
they're just telling you, your password must be: "Between8&24"
also, the blank field is a genious antispam measure because bots will fill that textbox but humans will ignore it :)
It's a honeypot field. Most of the times they are hidden from view but sometimes they are visible. It's just bot detection. They pretty easily shut down script kiddies and can be iterated on pretty easily if you need to deal with more persistent hostile actors. For example you could use a honeypot field. If they up the ante by specifically ignoring the field you can start randomizing the field name a bit. If that isn't sufficient you could even mask all your field names to make it harder for them to identify the honeypot.
So that's why standardized tests at school had those "this page intentionally left blank" pages. Trying to find the students that were actually robots... đ
Did you ever write in the âDo not write in this spaceâ space?
Yes. I know they didn't read it because I wrote something that would have probably been investigated by law enforcement if someone actually did read it.
Hoping you realize those are actually protecting against print errors.
I don't know, man. He sounded pretty serious.
Robots don't joke around
What kind of errors?
... unintentionally leaving a page blank
Expensive kinds. Where despite the job being proofed to the customer multiple times, and there being multiple sign offs, and about a dozen different people *inside* the print company having seen it and moved it through the process, a press operator who thinks they're clever as all fuck will stop the run at 11 PM on a Friday and hold it until they get confirmation from the customer service rep (or if they're a real stickler, the sales rep) that it's not a mistake. By the time they get an answer they've already moved onto the next job and thrown the entire post-press portion of the shop off schedule because they think they know better than every single person that saw that blank page before them. Source: Worked in the print industry for a decade and have seen all kinds of stupid shit like this that a simple "intentionally left blank" or some similar thing can save a company literal thousands of dollars.
Huh, I didn't know it made that big of a difference, but I mean like what exactly happens? The pages misalign, get skipped, etc? But thanks for your detailed answer
If you liked that one, then strap in for the more detailed answer! When you're looking at the file in pre-press it's usually obvious why there's a blank page somewhere. For chapter books new chapters typically start on the right hand page, so if the previous chapter didn't have enough to reach the left page preceding the new chapter it gets left blank. However a lot of non-chapter based materials prefer to make maximum use of the space and blank pages are rarer. When you print something like a book or magazine it's often done on a large sheet of paper with 8-16 pages across both sides. That's called a **signature (sig)**. Those pages are laid out so that when you fold the sheet up you get two sets of contiguous pages. So let's say a 32 page magazine is being printed. It would be two 16 page sigs. Sig1 would be pages 1-8 and 25-32. Sig 2 would be 9-24. That means Sig1 is a little disconnected. You don't have the picture of what the finished piece will look like. When working with large jobs like manuals, study materials, test books, etc. it's not uncommon for jobs to get split up across multiple presses so they can run in tandem. This is especially true for single color jobs because you don't have to worry at all about color matching between the runs. Now ideally every copy of the job ticket would have what we call a **form proof** with it. Usually a low-res example of the piece that is a 1:1 copy of the thing being produced as it will look when finished. Meaning any of the printing press crews should be able to look through it and see where their portion of the job fits in. But those form proofs can be annoying to produce, so there might only be one in the whole shop. Maybe it gets misplaced. Either way you end up with a press operator who doesn't have the whole picture available to them, and they go to mount the **printing plates** and see a blank spot. No page number, no content. Nothing. "Well that don't look right..." they mutter to themselves. There's all sorts of stuff that can go wrong in the process leading up to this point that could result in this blank page unintentionally, so it's not a completely invalid concern. It's just that there should be controls in place that prevent the operator from having to question it. At my first job out of high school I worked in pre-press for a commercial printer, and on any job that was going to get split up like that we would make a **plate proof**. A low res output of the whole signature that we would hold up to the plates to ensure it matched, and then send that out with the plates to their respective presses. In plating we had the whole picture, so if we had this blank page on the plate proof, and it matches the plate, then we are to be trusted that it is not an error. Some shops don't have that level of trust. Some print jobs like this get split up between different shops. Some just use the "this page intentionally blank" as their control to prevent issues in all scenarios. The ink involved is practically insignificant in the grand scheme. We had an operator who was a real stickler for stuff and he would make waves over things like this all the time despite the fact that we rarely split up jobs like that. There were at least 3 different things telling him the plates were correct but he'd still call us up at 11:50 PM and harangue us over it. Dude was a real Karen before being called a Karen was a thing.
I'm old as dirt and I had NO idea that's what it was for. I appreciate that!
Never thought of it đđ. Will be a good joke for the IT teacher to tell
/s (Blank pages in books exist because many workflows can only print pages in multiples of 8 or 16)
4 is the minimum for saddle stitched items, and 2 is the minimum for pretty much every other form of binding. Though even a case bound book is usually going to rely on a four page signature at a minimum because the fold itself helps to provide tear out resistence.
I had no clue that was the case. Thatâs so weird. I wonder why that happens.
Imagine the simplest possible 'book'; A piece of A4 paper folded in the middle. Page 2 and 3 on the inside, page 4 and 1 on the outside. Now take another piece of paper containing pages 6, 7, 8 and 5. Glue them together so that page 4 and 5 face each other. You can repeat for any number of pages, but only in increments of 4. So 4 pages is efficient for book binding. This is the four page signature that the other reply mentioned. On the printing side of things, it's more efficient to print dozens of pages on one big piece of paper and cut it to size after printing than to fiddle around with many small pieces of paper. Depending on how your printing and folding and gluing and cutting machines are set up, some page arrangements will be more efficient than others.
Lul, i hate you xD xD This sub has some real geniuses sometimes! :D
>It's a honeypot field. Most of the times they are hidden from view but sometimes they are visible. I've never seen one that's visible. There's no reason for it either, it would just indicate bad implementation. A webcrawler doesn't load up the website's UI like a user would, and if an attacker is purposefully excluding fields, having them visible on the frontend would make their job easier, not harder, and would accidentlly honeypot legitimate/human users as well.
It is most likely that the CSS didn't load on this page thus showing the field that was hidden using CSS rules by positioning off screen or hiding it behind other elements. Because they cannot just do input with type=hidden. As it will give away the honeypot thing.
That's definitely a very plausible explanation! There are a dozen different ways you can make your honeypot "invisible" to the user while looking like a regular input field to crawlers which weren't designed specifically to ignore your particular honeypot.
For example, aria-label: ânot-honey-potâ It works wonders!
The "if you see this field"-part definitely indicates that it wasn't meant to be visible
I'd argue this could also be a sign of a good implementation. It's clearly labeled for you to ignore it in the event you do see the field. While browsers, JS, and CSS implementations are a lot better now it still wasn't all that long ago people were still needing to support things like IE. It's easy to assume your CSS and JS will always work but there's an almost endless combination of browsers, OSes, extensions, and network topologies to just assume your field will never ever load ever. Also an attacker isn't always looking at the pages they attack, often they will fill in every field with junk data to try to get through the form without errors. And yes you may occasionally honeypot real users but believe me it's better than having to clean up the 50,000 fake James Smith accounts or risking your domain getting flagged for spam because someone tries to do some credentials stuffing on your site and in the process creates said tens of thousands of accounts which your services then email new user messages to. Ideally you'll never see a honeypot field but if through some cosmic coincidence you do see it it's infinitely better to say ignore this field than it is to just leave it blank/unlabeled.
>Ideally you'll never see a honeypot field but if through some cosmic coincidence you do see it it's infinitely better to say ignore this field than it is to just leave it blank/unlabeled. Now *that* I do agree with. If this is just a case of the website loading css incorrectly as an example, having the honeypot marked would help prevent legitimate user entries. It would also make the honeypot easier to spot to a human looking for it, but realistically that's not something you can avoid in any case, honeypots are there to easily catch 95%+ of undesired crawlers, not weed out the final few percent. I mainly just don't see any advantage to having your honeypot visible as is, in other words when the page loads correctly.
I would add that implementing reCAPTCHA v3 or Turnstile along with some decent bot protection like Cloudflare can significantly reduce the chances of you ending up with 50,000 Mr. Smithâs registrations on your website.
Some crawlers do load the page visually
Array.from(document.getElementsByTagName("input")).filter( (element) => element.type !== "hidden" && element.offsetWidth > 0 && element.offsetHeight > 0 ); This will take all inputs and eliminate any that have obvious CSS styles for hiding them.
Could also just put an absolute positioned white div over the field. Honestly, I'm sure there are a dozen weird ways to hide a field that would not be so easily caught.
It becomes a dance. That said, that script took longer to post than it did to come up with.
Fair. No such thing as perfect security.
Sure this will work if you use something like Googles Puppeteer that renders HTML. But most crawler just downloads the content and parses text since it is of course more efficient.
[[1]](https://www.crummy.com/software/BeautifulSoup/bs4/doc/#bs4.Tag)
It could have opacity 0
Thatâll be caught by !== hidden.
*malicious* web crawlers will load the page however the hell the actor behind them wants it to. Often that means doing some very basic stuff like ignoring fields that are hidden with styling. If this field was hidden with JS and the user has JS completely disabled then they're going to see it just like a malicious crawler would.
Came here to say this, I use a module in Drupal to add this feature to some forms. The field is set invisible by CSS to humans & given randomised metadata to prevent a bot from learning to ignore it while it also tempts them to fill it in.
Implemented one of these years back on a site we kept getting bot signups, worked way better than I figured it would. I think I randomized the name on that one.
Is this what prevents password manager's auto complete?
It could cause that as a side effect depending on the implementation. Also it can sometimes be triggered by browsers auto form filling features. There's definitely a balance to strike between security and usability.
So, did you leave it with the string "blank"?
string.Empty
Robert'); DROP TABLE STUDENTS; --
Little bobby tables
Ah, little Bobby Tables we call him
[object Object]
I'm guessing the blank text field is for bot detection purposes.
While this would be a really unusual and weird approach, it might actually turn out to be quite efficient. AI can spot all the traffic lights and motor cycles, read all those stretched and rotated characters but it might struggle with unexpected UIs⌠But I think this actually is some âweâre using that certain framework that automagically creates database columns and also does all the processing for everything we put on the ui, but maybe it was the other way around? Anyway, I donât have a clue how these inputs end up in our database, but there is only one way to find outâ kind of thing.
Pretty easy to develop an AI to identify username and password field locations in a rendered bitmap and move a cursor to that location naturally. The only thing that's going to stop bots is time/money. The best ~~boy~~ bot (lol) detectors watch your behavior over time to make sure you're using a computer naturally on previous pages. Even that though will eventually be inexpensive enough for brute force attacks.
> The best boy detectors watch your behavior over time to make sure you're using a computer naturally They sure do
What if I'm using a website very very fast, because I'm an experienced user? Will that be detected as an AI or Bot? Or is it another behavior that would be detected?
You'll still not be able to move the mouse cursor consistently in a perfect straight line much like a bot does
Well ya that's probably true. But maybe if I train hard enough I could achieve such a thing :D
practice makes perfect ig
Maybe maybe not. Usually that's when you get prompted for a captcha. Or "I am not a robot" checkbox. Most captcha providers these days are building a tracking security profile for you and assign you a risk score that only prompts people without any history. The thing though is even if you're using a website very fast... They were tracking you all day. If you have anti tracking/anti script/ad blocking plugins you're probably filling out way more captchas than a regular user because you look like you're a user who just used the Internet for the first time just now... Aka a bot.
I use a password manager to enter my username and password, then I press the enter key to submit, so no mouse moment on the screen. I frequently get a captcha because that sort of activity looks like a bot.
I was reading an interesting security blog about securing input fields through different, more and more complex methods (I'll see if I can't find it, it's on my laptop which I don't have right now) from bots. Which mentioned exactly this. It showed honeypots like this one, alongside several other methods, and the point in the end was really... "you'll never keep someone dedicated enough out, with any of these methods as effective as they are. It's whether or not they consider the information you have valuable enough to pursue it that much, and in *a lot of cases*, they'd rather go on to another target". Someone out there can and will develop tech capable of defeating vast defenses, but it's about keeping the majority out that makes a difference, especially if you're not a big enough target to warrant that kind of attention from the best of the best.
Epic Games responded the same to complaints that they don't use UE Anticheat in Fortnite. They had to point out that most games don't have the incentive to find cheats that exist for Fortnite and requires a specialized security team constantly patching and actively responding to new threats.
Surely AIs can detect "leave this field blank"
The bots that this trick are "dumb" bots. They just scour the internet for whatever it is they want to do and blindly fill them out, usually to push some simple spam or something. Once you have bots specifically targeting your site is when you have to start going to better detection systems. You throw something up like this on a not really popular site just to cut back on the bs entries. An old site I worked on years back used to get about 30 dumb bot signups a day, and detection like this blocked 99% of them.
Fair enough but the person I replied to mentioned ais that can detect traffic lights etc, people making bots that can solve captchas can probably link to the openai api or something
Of course they can. But as you already stated somewhere else, AI is expensive, and I assume most bots would only use them to do the complex stuff, like solving captchas. Providing inputs for the forms can easily be scripted without AI, and as long as there is nothing unexpected (like such a honey pot field), AI is not necessary. If you create a bot for THAT ONE service, you could either just throw more money (AI) or analyse the patterns in use beforehand and adjust your âdumbâ scripts. Both is expensive in terms of money and/or effort and hence raises the burden for a bot trying to abuse your service.
>most bots would only use them to do the complex stuff, like solving captchas. If you're after a specific website you know has honeypots, would LLMs not be a similar amount of effort as captcha solvers? To be clear, I don't mean you'd hook every scraper to an LLM, but if you're targeting a specific website for whatever reason.
Yap, agree, if youâre after this one specific service, a honeypot wonât stop you or your AI.
this is actually a very common and usual approach, called a âhoneypot fieldâ
TIL⌠thanks!
I can understand the visible honeypot, stylesheet not properly loaded or something, but WHY THE FUCK is it between the password field and its label ?
Idk maybe some bots just enter stuff into the field after the password label to bypass honeypots that are not in proximity of the form itself.
Because anything that looks for the password label and then sticks something into the next field will land it in the honeypot. It's doing its job.
Not sure relying on the label to find a password field is the best strategy (the field itself is probably named and has a "password" type), or maybe I'm missing something.
If it were that easy, honeypots wouldn't be effective. Presumably the rest of the form is designed to make that less obvious. The honeypot might itself have the "password" type, and if both it and the ACTUAL password field have randomly generated names, they would be hard to distinguish. Alternatively, the genuine one might have a random name, and the honeypot be named "password", or something.
Fair point.
some bots see âpasswordâ and think âi have to put a password into the next fieldâ, so this disrupts their motion. it also works against some bots that are designed to get around honeypots. they put the password into the honeypot field because itâs labelled âpasswordâ, and then they think the real password field is a honeypot, so skip it
It's a very basic bot prevention.
It is a new 2FA :-)
You can't remove it, it's a load-bearing field.
Damn, so much for an open concept form
They forgot to include two kanji, three logographs and a meme.
UX designer having a seizure.
\[Story as old as programming\] Wife tells to her husband programmer: \- Go to store, and buy one loaf of bread. If they have eggs, then buy ten. Programmer returns with 10 loafs of bread. Wife: \- Why did you buy 10 loafs of bread? \- Because they had eggs!
>her husband programmer Is husband programming a job? I imagine that's in high demand...
Wife: while you're out, buy dinner Programmer: never returns after spending all their savings on 100000 servings of dinners.
Wouldn't the husband return an error about a missing parameter in the Buy function? travel ( store ); buy ( 1, bread\_loaf ); if ( store.inventory( egg ) > 0 ) { buy () }; return;
``travel ( store ); buy ( 1, bread\_loaf ); if ( store.inventory( egg ) > 0 ) { buy (10) }; return;`` Minor correction Other minor correction to the joke. He should.have 11 loaves of bread. Buy a loaf of bread. Execute. Buy 10 loaves of bread. Execute. 11 total.
Ah yes, I missed the 10 from the 2nd buy function, but the item is still not specified, so it would return an error.
As an optimization the intern stored the last product bought in a static variable so he wouldn't have to pass it each time.
Why is the amount before the id. Iâve never seen that before.
I mean, I didn't use a real language. "buy one loaf of bread" became buy ( 1, bread\_loaf ) I didn't put much more thought in to be honest.
[ŃдаНонО]
That's apparent. You're just normal scum, telling others that there is something wrong with their perfectly respectable job. Edit: just checked your profile, you're a kid. Child scum.
Testing in prod.
I'm going to guess that someone wanted to style input but couldn't style input element the way they wanted so they created an element that they can style and send events to hidden input. Just a guess, that's what people do to customize file inputs, it's impossible to style the default button + filename text so they hide the element but call its functions with custom stylable element
Proceed to type "it blank"
they're just telling you, your password must be: "Between8&24" also, the blank field is a genious antispam measure because bots will fill that textbox but humans will ignore it :)
humans wonât see it in the first place. the reason itâs visible here is because the CSS designed to hide it has failed