88 stories

Testing Security Keys


Last time I reviewed various security keys at a fairly superficial level: basic function, physical characteristics etc. This post considers lower-level behaviour.

Security Keys implement the FIDO U2F spec, which borrows a lot from ISO 7816-4. Each possible transport (i.e. USB, NFC, or Bluetooth) has its own spec for how to encapsulate the U2F messages over that transport (e.g. here's the USB one). FIDO is working on much more complex (and more capable) second versions of these specs, but currently all security keys implement the basic ones.

In essence, the U2F spec only contains three functions: Register, Authenticate, and Check. Register creates a new key-pair. Authenticate signs with an existing key-pair, after the user confirms physical presence, and Check confirms whether or not a key-pair is known to a security key.

In more detail, Register takes a 32-byte challenge and a 32-byte appID. These are intended to be SHA-256 hashes, but are opaque and can be anything. The challenge acts as a nonce, while the appID is bound to the resulting key and represents the context of the key. For web browsers, the appID is the hash of a URL in the origin of the login page.

Register returns a P-256 public key, an opaque key handle, the security key's batch certificate, and a signature, by the public key in the certificate, of the challenge, appID, key handle, and public key. Since the security keys are small devices with limited storage, it's universally the case in the ones that I've looked at that the key handle is actually an encrypted private key, i.e. the token offloads storage of private keys. However, in theory, the key handle could just be an integer that indexes storage within the token.

Authenticate takes a challenge, an appID, and a key handle, verifies that the appID matches the value given to Register, and returns a signature, from the public key associated with that key handle, over the challenge and appID.

Check takes a key handle and an appID and returns a positive result if the key handle came from this security key and the appID matches.

Given that, there are a number of properties that should hold. Some of the most critical:

  • The key handle should be encrypted; i.e. we shouldn't be able to find an ECDSA private key in there.
  • A key handle from one security key should not work with another, even of the same type.
  • If a security key is asked to generate hundreds of key-pairs, they should all be distinct.
  • All the signatures should have unique nonces, otherwise you have the PlayStation bug and can extract private keys.
  • The appID should actually be checked.

But there are a number of other things that would be nice to test:

  • Does the key handle have patterns? Ideally it would be indistinguishable from random to outside observers.
  • Is the key handle mutable? Really the whole thing should be authenticated.
  • Are the signatures correctly encoded? It's a very simple structure, but it's ASN.1 so there are corner-cases.
  • The USB protocol transmits 64-byte packets, the padding bytes at the end should all be zero, not random bits of memory. Are they?

So given all those desirable properties, how do various security keys manage?


Easy one first: I can find no flaws in Yubico's U2F Security Key.

VASCO SecureClick

I've acquired one of these since the round-up of security keys that I did last time so I'll give a full introduction here. (See also Brad's review.)

This is a Bluetooth Low-Energy (BLE) token, which means that it works with both Android and iOS devices. For non-mobile devices, it includes a USB-A BLE dongle. The SecureClick uses a Chrome extension for configuring and pairing the dongle, which works across platforms. The dongle appears as a normal USB device until it sees a BLE signal from the token, at which point it “disconnects” and reconnects as a different device for actually doing the U2F operation. Once an operation that requires user-presence (i.e. a Register or Authenticate) has completed, the token powers down and the dongle disconnects and reconnects as the original USB device again.

If you're using Linux and you configure udev to grant access to the vendor ID & product ID of the token as it appears normally, nothing will work because the vendor ID and product ID are different when it's active. The Chrome extension will get very confused about this.

However, once I'd figured that out, everything else worked well. The problem, as is inherent with BLE devices, is that the token needs a battery that will run out eventually. (It takes a CR2012 and can be replaced.) VASCO claims that it can be used 10 times a day for two years, which seems plausible. I did run the battery out during testing, but testing involves a lot of operations. Like the Yubico, I did not find any problems with this token.

I did have it working with iOS, but it didn't work when I tried to check the battery level just now, and I'm not sure what changed. (Perhaps iOS 11?)

Feitian ePass

ASN.1 DER is designed to be a “distinguished” encoding, i.e. there should be a unique serialisation for a given value and all other representations are invalid. As such, numbers are supposed to be encoded minimally, with no leading zeros (unless necessary to make a number positive). Feitian doesn't get that right with this security key: numbers that start with 9 leading zero bits have an invalid zero byte at the beginning. Presumably, numbers starting with 17 zero bits have two invalid zero bytes at the beginning and so on, but I wasn't able to press the button enough times to get such an example. Thus something like one in 256 signatures produced by this security key are invalid.

Also, the final eight bytes of the key handle seem to be superfluous: you can change them to whatever value you like and the security key doesn't care. That is not immediately a problem, but it does beg the question: if they're not being used, what are they?

Lastly, the padding data in USB packets isn't zeroed. However, it's obviously just the previous contents of the transmit buffer, so there's nothing sensitive getting leaked.


With this device, I can't test things like key handle mutability and whether the appID is being checked because of some odd behaviour. The response to the first Check is invalid, according to the spec: it returns status 0x9000 (“NO_ERROR”), when it should be 0x6985 or 0x6a80. After that, it starts rejecting all key handles (even valid ones) with 0x6a80 until it's unplugged and reinserted.

This device has the same non-minimal signature encoding issue as the Feitian ePass. Also, if you click too fast, this security key gets upset and rejects a few requests with status 0x6ffe.

USB padding bytes aren't zeroed, but appear to be parts of the request message and thus nothing interesting.

U2F Zero

A 1KiB ping message crashes this device (i.e. it stops responding to USB messages and needs to be unplugged and reinserted). Testing a corrupted key handle also crashes it and thus I wasn't able to run many tests.


The Key-ID (and HyperFIDO devices, which have the same firmware, I think) have the same non-minimal encoding issue as the Feitian ePass, but also have a second ASN.1 flaw. In ASN.1 DER, if the most-significant bit of a number is set, that number is negative. If it's not supposed to be negative, then a zero pad byte is needed. I think what happened here is that, when testing the most-significant bit, the security key checks whether the first byte is > 0x80, but it should be checking whether it's >= 0x80. The upshot is the sometimes it produces signatures that contain negative numbers and are thus invalid.

USB padding bytes aren't zeroed, and include data that was not part of the request or response. It's unlikely to be material, but it does beg the question of where it comes from.

The wrapped keys also have some unfortunate properties. Firstly, bytes 16 through 31 are a function of the device and the appID, thus a given site can passively identify the same token when used by different accounts. Bytes 48 through 79 are unauthenticated and, when altered, everything still works except the signatures are wrong. That suggests that these bytes are the encrypted private key (or the encrypted seed to generate it). It's not obvious that there's any vulnerability from being able to tweak the private key like this, but all bytes of the key handle should be authenticated as a matter of best practice. Lastly, bytes 32 through 47 can't be arbitrarily manipulated, but can be substituted with the same bytes from a different key handle, which causes the signatures to be incorrect. I don't know what's going on there.

Overall, the key handle structure is sufficiently far from the obvious construction to cause worry, but not an obvious vulnerability.

Read the whole story
7 days ago
Share this story

Equifax Breach Fallout: Your Salary History

2 Comments and 5 Shares

In May, KrebsOnSecurity broke a story about lax security at a payroll division of big-three credit bureau Equifax that let identity thieves access personal and financial data on an unknown number of Americans. Incredibly, this same division makes it simple to access detailed salary and employment history on a large portion of Americans using little more than someone’s Social Security number and date of birth — both data elements that were stolen in the recent breach at Equifax.


At issue is a service provided by Equifax’s TALX division called The Work Number. The service is designed to provide automated employment and income verification for prospective employers, and tens of thousands of companies report employee salary data to it. The Work Number also allows anyone whose employer uses the service to provide proof of their income when purchasing a home or applying for a loan.

The homepage for this Equifax service wants to assure visitors that “Your personal information is protected.”

“With your consent your personal data can be retrieved only by credentialed verifiers,” Equifax assures us, referring mainly to banks and other entities that request salary data for purposes of setting credit limits.

Sadly, this isn’t anywhere near true because most employers who contribute data to The Work Number — including Fortune 100 firms, government agencies and universities — rely on horribly weak authentication for access to the information.

To find out how easy it is to view your detailed salary history, you’ll need your employer’s name or employer code. Helpfully, this page lets you look that up quite easily (although if you opt to list employers alphabetically by the fist letter of the company name, there are so many entries for each letter that I found Equifax’s database simply crashes half the time instead of rendering the entire list).


What’s needed to access your salary and employment history? Go here, and enter the employer name or employer code. After that, it asks for a “user ID.” This might sound like privileged information, but in most cases this is just the employees’s Social Security number (or a portion of it).

At the next step, the site asks visitors to “enter your PIN,” short for Personal Identification Number. However, in the vast majority of cases this appears to be little more than someone’s eight-digit date of birth. The formats differ by employer, but it’s usually either yyyy/mm/dd or mm/dd/yyyy, without the slashes.

Successful validation to the system produces two sets of data: An employee’s salary and employment history going back at least a decade, and a report listing all of the entities (ostensibly, the aforementioned “credentialed verifiers”) that have previously requested and viewed this information.

Once you’re successfully “authenticated,” the system asks you to change your PIN to something more secret than your birthday. When the default PIN is changed, The Work Number prompts users to select a series of six challenge/response questions, which Equifax claims will “improve the security of your data and create an extra layer of protection on your account.”

Unfortunately, consumers whose employee history is stored by this service effectively have no privacy or security unless they possess both the awareness that this service exists and the forethought to access their account online before identity thieves or others do it first.


The Work Number does allow employers to opt for TALX’s “enhanced authentication” feature, wherein after logging in with your employer ID and PIN (often the last four digits of an SSN plus the birth year), the system is designed to require the requester to respond to an email at a work address or a phone call to a work number to validate the login.

However, I did not find this to be the case in several instances involving readers whose employers supposedly used this enhanced authentication method. In cases where corporate human resources departments fail to populate employee email addresses and phone numbers, the system defaults to asking visitors to enter any email address and phone number to complete the validation. This is detailed here (PDF), wherein The Work Number states “if you do not have the required phone and e-mail information on file, you will be prompted to update/add your phone numbers/email addresses.”


Worse yet, while companies that use this service tend to vary their approaches to what’s required in terms of user IDs and PINs, a great many employers publish online detailed instructions on how to fill out these various forms. For example, the State of California‘s process is listed here (PDF); instructions for the Health Resources & Services Administration (HRSA) are here; employees at the National Institutes of Health (NIH) can learn the steps by consulting this document (PDF). The process for getting this information on current and former UCLA employees is spelled out here. There are countless other examples that are easy to find with a simple Internet search.

Many readers probably consider their current and former salaries to be very private information, but as we can see this data is easily available on a broad spectrum of the working population in America today. The information needed to obtain it has been widely compromised in thousands of data breaches over the past few years, and the SSN and DOB on most Americans is for sale in a variety of places online. In short, if you can get these details from Equifax’s online service, so can anyone else.

Fortunately, you can reduce the likelihood that an acquaintance, co-worker, stalker or anyone else can do this by claiming your own account, changing the PIN and selecting a half-dozen security questions and answers. As always, it’s best not to answer these questions truthfully, but to input answers that only you will know and that can’t be found using social networking sites or other public data sources.

I could see this service potentially helping to create a toxic workplace environment because it offers a relatively simple method for employees to glean data about the salaries of their co-workers and bosses. While some people believe that companies should be more transparent about employee salaries, this data in the wrong hands very often generates a great deal of resentment and hostility among co-workers.

Employers who use The Work Number should strongly consider changing as many defaults as possible, and truly implementing the service’s enhanced authentication features.

October is National Cybersecurity Awareness Month, and as such KrebsOnSecurity will continue pointing readers to similar services that let anyone access your personal data armed with little more than static identifiers about you that should no longer be considered private. Although some readers may take issue with my pointing these out — reasoning that I’m only making it easier for bad people to do bad things — it’s important to understand that knowledge is half the battle: Planting your flag before someone else does is usually the only way to keep others from abusing such services to expose your personal information.

Related reading:

USPS ‘Informed Delivery’ is Stalker’s Dream
Student Aid Tool Held Key for Tax Fraudsters
Sign Up at IRS.gov Before Crooks Do It For You
Crooks Hijack Retirement Funds via SSA Portal
Social Security Administration Now Requires Two-Factor Authentication
SSA: Ixnay on txt msg reqmnt 4 e-acct, sry

Read the whole story
8 days ago
Share this story
2 public comments
6 days ago
theworknumber has been down for "maintenance" since the weekend, and of course this happens when i actually need to get data from it
Dallas, Texas
9 days ago
Really, people? Sigh.
Central Indiana

Researchers may have found a CTE test for living patients

1 Comment and 2 Shares

Currently, the only way to diagnose chronic traumatic encephalopathy (CTE), a disease caused by repeated head trauma, is by posthumously examining brain tissue for signs of tau protein buildup. But a group from Boston University may have found a way to test for CTE in living patients.

McKee and her team discovered a specific biomarker in the brains of former football players. A biomarker is a measurable substance which is, in this case, found in the brain and identifies an abnormality.

This particular biomarker is called CCL11, and it’s a secreted protein the human body uses to help regulate the immune system and inflammation in the body.

As The Ringer’s Claire McNear writes, if a CTE test is easily available to players, what will that do to football? (Or indeed, what will it do to sports like soccer, boxing, skateboarding, or even skiing?)

“After learning all of this,” the retiring Ferguson wrote of the clarity he gained when he began researching CTE, “I feel a bit betrayed by the people or committees put in place by the league who did not have my best interests at heart.” He should feel betrayed, as should many of his fellow players. As will, certainly, so very many, once they have the ability to see what has happened to them. They may wonder, rightfully, about the people who trained them and paid them, sometimes even as they attempted to shut down research into CTE. They may look at the league’s structure, at the lopsided contracts that rob many players of their leverage, forcing them to choose between getting back on the field or losing a paycheck (and possibly getting cut), and at how the league cycles through players like they’re nothing more than easily broken pieces on a board.

Tags: Claire McNear   football   medicine   NFL   science   sports
Read the whole story
9 days ago
Share this story
1 public comment
18 days ago
New York, NY

Self Driving

4 Comments and 20 Shares
"Crowdsourced steering" doesn't sound quite as appealing as "self driving."
Read the whole story
14 days ago
Share this story
4 public comments
14 days ago
So much this.
Arlington, VA
15 days ago
"Crowd Sourced Steering" doesn't quite sound as appealing as "self driving".
iPhone: 49.287476,-123.142136
15 days ago
Atlanta, GA
15 days ago
Outsourcing AI work to people

How a Werfalli Execution Site Was Geolocated

1 Comment and 2 Shares

This article was collaboratively researched and written by Timmi Allen, Klement Anders, Daniel Romein, and Christiaan Triebert of the Bellingcat Investigative Team.


In August 2017, the International Criminal Court (ICC) issued its first ever arrest warrant solely based on social media evidence. The arrest warrant accuses Mahmoud Mustafa Busayf Al-Werfalli (hereafter referred to as ‘Werfalli’), an alleged commander of the Al-Saiqa Brigade of the Libyan National Army (LNA), of mass executions in or near Benghazi.

Bellingcat has highlighted the importance of this development, which aligns the ICC with the realities of many of today’s conflicts, in an earlier article. The article marked the start of a crowdsourcing campaign to geolocate the seven locations of the executions on which the arrest warrant is based. Four execution sites have been geolocated so far, and one of them – Incident Seven – is worth discussing in further depth as it is an excellent example of team work and using a wide variety of open source information such as satellite imagery, geotagged photos, conflict context, geolocations from other sources and news articles.

The Evidence: A Facebook Video

The video which prompted the ICC arrest warrant was uploaded on July 23, 2017, by a Facebook user named ‘Mohammed Al-Gali’. The video has been deleted since, though an archived version exists.

The video shows the execution of twenty individuals who are, according to the description, “terrorists found guilty of kidnapping, torture, killing, bombing, and slaughtering” and members of the so-called Islamic State (IS). Mohammed Al-Gali appears to have a direct link with the military unit led by Werfalli, as numerous videos and photographs on his Facebook document events related to them. It is possible that he is the individual who filmed the executions. Werfalli is visible in the video and gives the order to execute the group of twenty individuals. According to the arrest warrant, Werfalli reads from a white document in the video of Incident Seven, and refers to a ‘decree decision’, which ‘shall be executed today 17/07/2017’.

The first part of the video shows the execution of eighteen people and the second part the execution of another two people. The long shadows in the video indicate it was filmed in the early morning (from north to south) or late afternoon (from south to north).

The Geolocation: Bushes, Buildings, and Blood Stains

At first sight the video seems very difficult to geolocate, because of the apparent lack of identifiable landmarks. Aside from the twenty executed people, their executioners and a white car, mainly a desert landscape with two sand tracks, a few sand hills and some vegetation is visible. However, a stitched panorama of the video, published in Bellingcat’s previous article, shows buildings and a fence on a distance in the background.

The buildings are visible for less than a second, at 3m25s. A fence consisting of poles is visible in the second part of the video, from 4m19s onward. Besides the vegetation pattern, these are the only visual clues to go on for the geolocation.

Image 1. A panorama of the execution site of Incident Seven. The panorama is composed out of stills of the Facebook video.

Image 2. A still from the Incident Seven video at 3m25s, showing the structures in the background of the execution site.

Image 3. A fence is visible in the background of a still of the video at 4m25s.

The Bellingcat team was able to geolocate the video in Ghanfuda, which is situated in the western part of Benghazi.

The video was filmed from north to south, very likely on July 17, 2017, approximately at 6:37 am. The coordinates of the execution area are 32.023144, 20.029181.

Image 4. The location of the execution site as shown on Google Earth. The buildings and the fence shown in the Incident Seven video are highlighted in red rectangles, and the blue lines mark the area that was filmed in the video. Copyright DigitalGlobe ©​ 2017

Image 5. Screenschot of SunCalc at the execution location at 17 July 2017, 6:37 am.

Image 6. An overlay of a still of the Incident Seven video on satellite imagery with a 3D reconstruction of the buildings in that area.

On satellite imagery, vegetation patches and a hill are visible. These features directly correspond with the vegetation patches and hill which are visible in the Incident Seven video. Furthermore, the two sand tracks shown in the video are clearly visible on the satellite imagery.

Image 7. Top: Stitched panorama made out of stills from the execution video, vegetation marked in green rectangles, hill in brown rectangle. Bottom: The area on satellite imagery with the same vegetation marked in green rectangles, hill in brown rectangle, the red circle marks the position of the camera. Satellite imagery copyright DigitalGlobe ©​ 2017

Traces of the execution are also distinctly visible on July 17, 2017, satellite imagery of TerraServer. The satellite image’s resolution is 0.30m, the highest resolution available for consumers. Fifteen black spots are visible, which are very likely blood stains of the executed people. These spots are at the exact same location as where the twenty individuals were shot. Satellite imagery of the 11th and 14th of July 2017 clearly shows these spots were not visible yet on those dates.

Image 8. Left: satellite imagery of 11 July 2017, no spots visible inside the red circle. Right: satellite imagery of 17 July 2017, approximately 15 spots visible inside the red circle. Copyright DigitalGlobe ©​ 2017

Image 9. Comparison of the location of the bodies in the video and the spots in the satellite imagery makes clear the bodies in the video and the spots in the satellite imagery are on exactly the same location.

How Was the Location Found?

As mentioned in the previous article about the Werfalli executions, the buildings in the left upper side of the panorama gave a strong clue about the location of the video. The buildings visible in the video seem to be gray concrete buildings with “arches” without doors.

Twitter user @ROELart mentioned that the video possibly was filmed in a southwest area of Benghazi because the color of the sand is more grey than in other areas of Benghazi, where colors of the sand are more orange or yellow.

In that area we noticed many concrete buildings that were not finished yet, such as an area with new buildings that is named ‘Bingazi Meammar’, located to the southwest of Benghazi, as described on Wikimapia.

Another area with ‘Chinese Buildings 24’ is mentioned on Wikimapia as an area captured by the Libyan National Army (LNA) from the Benghazi Revolutionaries’ Shura Council (BRSC) in January 2017. These buildings are a part of a much bigger project of new real estate, developed by China, for 25.000 housing units in the Ghanfuda area. Construction of the ‘Chinese Buildings’ started in 2008 or 2009, but stopped in 2011 because of the civil war in Libya and thousands of Chinese construction workers left Libya. The same year there were plans to continue the construction, but that never happened and the construction never was completed. In January 2017 terrorists were hiding inside ‘Buildings 12’, likely an area with 12 buildings in Ghanfuda, Benghazi.

One photograph of the ‘Chinese Buildings’ strongly resembles to the buildings visible in the execution video, especially because of a structure where the front and side of the building are alternated. Satellite imagery of ‘Chinese Buildings’ confirmed the strong similarity. However, since the area consist of hundreds of these buildings, geolocating the right spot seemed a very difficult task.

Image 10. Buildings in the execution video (top) compared to the ‘Chinese Buildings’ (bottom).

Image 11. Similarities between the ‘Chinese Buildings’ on satellite imagery (top) and the buildings visible on a distance in the execution video (bottom).

Mohammed Al-Gali, the person who likely filmed the executions and also was likely involved in filming other executions by Werfalli in 2016 and 2017, uploaded several videos where similar unfinished concrete buildings are visible. On 2 February 2017 he uploaded a video showing a panorama view around, filmed from the roof of one of the buildings. This video could be geolocated to  32° 1’31.29″N, 20° 1’48.84″E (32.025358, 20.030233) in a north western corner of the area with ‘Chinese Buildings’ in Ghanfuda. The description of the video likely refers to the ’12 buildings’ where terrorists were hiding and a battle against these terrorists.

Image 12. Screenshot of the 2 February 2017 video, showing an area with unfinished concrete buildings and several cranes. The description mentions ’12 buildings’ and a battle with terrorists, who were hiding there.

Two other videos, filmed on the 12th (but uploaded at the 13th) and 14th of June 2017, show a group of people, including Werfalli and what appear to be soldiers of his unit, digging up a large number of munition and weapons, buried by the terrorists, with a bulldozer. These videos were geolocated at 32° 1’40.13″N, 20° 1’43.89″E (32.027814, 20.028858) and  32° 1’37.65″N, 20° 1’42.59″E (32.027125, 20.028497), just a few blocks of buildings away from the 2 February video location. Both videos mention that the ammunition and weapons were buried at sites inside ‘Chinese Buildings’.

Image 13. Screenshots from the 12 and 14 June 2017 videos, showing unfinished concrete buildings, according to the description weapons and munition were buried inside ‘Chinese Buildings’.

Image 14. Screenshots from the 12 and 14 June 2017 videos, showing unfinished concrete buildings, according to the description weapons and munition were buried inside ‘Chinese Buildings’.

The 12th June 2017 video shows similar white cars as visible in the execution video, although a definitive match between these cars could not be made.

Because the 2nd of February and the 12th and 14th June 2017 videos were filmed in the same area, Bellingcat expected the execution location to be in the same area as well. It was eventually a fence visible in the 12 June 2017 video that led to the execution location.

Image 15. A fence to the north of the buildings is visible in the 12 June 2017 video (marked in red rectangle).

On the northern side of the area with buildings and continuing to the western side of this area, a long fence consisting of poles leads from north to south. Following that fence to the south reveals an open area with several dirt tracks crossing each other. One of these crossings and the vegetation around turned out to be a perfect match with the landscape in the execution video.

Image 16. Google Earth satellite imagery showing the locations of the 2 February, 12 and 14 June 2017 videos. The 17 July 2017 execution video was filmed in the same area.


The geolocation of the execution video of Incident Seven of the Werfalli executions is a very strong match. The similarities between the vegetation, sand tracks, buildings, fence and spots on the exact location where the twenty individuals were executed, allows the conclusion that the exact location of the executions has been found. Changes to satellite imagery strongly indicates Mahmoud Al-Werfalli commanded the execution of twenty individuals on this location at some point between the 15th and 17th of July, 2017 during the early morning. Werfalli himself states in the video the execution took place on July 17th, which is consistent in the changes in the satellite imagery.

The post How a Werfalli Execution Site Was Geolocated appeared first on bellingcat.

Read the whole story
19 days ago
quite possibly the most interesting thing i've read in a while.
iPhone: 44.910601,-93.336335
16 days ago
Share this story

8 Things You Should be Making in your Waffle Iron

1 Share

This post is all about putting your waffle iron to use. We have a really great waffle maker, and I use it regularly, but pretty much only for my favorite waffles. It's the most egregious example of a single use appliance. So! I was chatting with a friend the other morning about the clever menu at The Riddler. It's a chic, little Champagne bar on a sunny corner in the Hayes Valley neighborhood of San Francisco. They don't have a traditional kitchen, but they do work wonders with a waffle iron and hot plate (w/ a glass of bubbles in hand). They make a now-famous Tater Tot Waffle, which got me thinking about all the other ways to use a waffle maker. Apparently I'm quite late to this party, because there are already tons of brilliant ideas out there. I've included a few that caught my attention here. Lastly, it seems like the trend is a lot of junk food meets waffle maker, so I tried to focus on more healthful (and savory) ideas! Let me know (in the comments) if you make anything clever in yours :) -h

1. Waffle Frittata with Tzatziki - (supergoldenbakes)
Making frittatas in your waffle maker is a thing. And, there are a lot of examples out there. That said, this is the one that caught my attention. Lots of herbs, cooked potatoes, chopped spinach - look at the color! Get the recipe here.

8 Things You Should be Making in your Waffle Iron

2. Pizza Waffles - (Jeff Garroway / Bijoux & Bits)
I came across this incredible photo (below) by Jeff Garroway. It's a decadent tower of crispy crusted, herb-flecked, cheesy pizza waffles. In the comments Jeff notes that he used the recipe from Bijou & Bites. I appreciate the idea that, like regular pizza, you can incorporate all sorts of seasonal sauces and ingredients, and keep the technique consistent. Get the recipe here.

8 Things You Should be Making in your Waffle Iron

3. Leftover Stuffing Waffles - (Just a Taste)
So, Thanksgiving is right around the corner, and everyone ends up with extra stuffing. Here's what happens when you put stuffing in your waffle maker. Use veg-broth / stuffing to keep them vegetarian. I'm thinking you also might be able to get away with a vegan version using flax eggs & vegan stuffing? Worth a try! Get the recipe here.

8 Things You Should be Making in your Waffle Iron

4. Crispy Sesame Waffled Kale - (KCRW Good Food)
Featured on the KCRW Good Food site, kale chips. But the twist here is, guess what? They're made in your waffle iron. Faster than doing an entire batch in the oven. Get the recipe here.

8 Things You Should be Making in your Waffle Iron

5. Waffled Polenta - (Julie's Jazz)
We've talked before about what to do with those tubes of polenta nearly everyone has in their pantry. I came up with this Lentil Polenta Casserole, but these Waffled Polentas blow that idea out of the water! Imagine all the different toppings you can deploy. Get the recipe here.

8 Things You Should be Making in your Waffle Iron

6. Leftover Mashed Potato Waffles - (Just a Taste)
Love this idea! I'd likely scale way back on the cheese, and use leftover mashed sweet potatoes for the added nutrition boost. Of course there are a thousand ways you could play around with the seasonings, and stir-ins as well! Get the recipe here.

8 Things You Should be Making in your Waffle Iron

7. Kimchi Fried Rice Waffles - (Miss Hangry Pants)
I often have left-over cooked rice & grains on hand. Check out this kimchi fried rice waffle. Such a smart idea, and would make a great component in a quick lunch. Get the recipe here.

8 Things You Should be Making in your Waffle Iron

8. Sarah Fit Healthy Waffle Iron Recipes (video)
Sarah talks through all the different ways she uses her $10 lil waffle iron. Some super fun ideas here - apple chips!?!

Continue reading 8 Things You Should be Making in your Waffle Iron...
Read the whole story
23 days ago
Share this story
Next Page of Stories