NExT Password, Does it really matter?

Got my first NExT installed Friday, after many months of waiting & planning, and am immediately excited about the possibilities. I used the neato ProxLF antenna and cloned the LF half of it while it was still in the sealed biopack. Confirmed that it worked with my HID Prox system while still in the biopack. So when I came home from the procedure it already opened the door flawlessly!! I giggled like a naughty child.

I added a couple records to the HF side with NFC Tools, that works (mostly - iPhone is a little quirky sometimes with reading).

Then I started looking to write-protect it with a password, and started reading the things. But here’s what concerns me. Doing an NTAG dump with the Proxmark literally prints the password clear as ASCII.

224/0xE0 | 00 00 00 00 | 0 | ....          
225/0xE1 | 4E 45 78 54 | 0 | NExT          
226/0xE2 | 00 00 7F BD | 0 | .... 

So questions:

  1. If it’s that easy to see what the password is set to, how much security does it really add?
  2. If I wanted to set that password and avoid the challenges with NFC Tools and mis-setting passwords, can I do that via the Proxmark? Or am I going to miss a check bit doing it that way and mess something up?

What did you set the password with? E1 is a regular sector. The password in an NTAG chip should go in E5. So I have a feeling it’s an application-specific “password”.

I haven’t tried setting any passwords yet. That’s the value that it arrived with. I just added a URL record, innocuous stuff like that.

But that’s interesting, because E5 is blank (or not dumped??)

224/0xE0 | 00 00 00 00 | 0 | ....          
225/0xE1 | 4E 45 78 54 | 0 | NExT          
226/0xE2 | 00 00 7F BD | 0 | ....          
227/0xE3 | 04 00 00 E3 | 0 | ....          
228/0xE4 | 00 05 00 00 | 0 | ....          
229/0xE5 | 00 00 00 00 | 0 | ....          
230/0xE6 | 00 00 00 00 | 0 | ....

E5 is write-only - it’s a password :slight_smile:

Ok, well that answers my security question, thanks! I guess it’s more secure than I gave it credit for… and the NExT value in there is just a little branding? :slight_smile:

I think maybe DT sticks “NExT” in E1 for cuteness. Perhaps… E1 is the end of user memory in the NTAG216. There’s nothing special about it to my knowledge - apart that TagWriter write-protects it for some reason.

1 Like

I’ll leave it, I think DT are badasses, they can brand my hand. :smiley:

I think I’m going to wait to set the password in case I want to change what’s stored in there, after everything I read on here it seems like it’s easy to have a software problem set your values wrong and lock you out of it.

You can always set a password, and then enter it to change stuff later on. In fact, you can set a password and only write-protect certain sectors, leaving all the others read/write. That’s what the DT app does: it write-protects certain critical sectors (preventing any other app from locking you out forever) but leaves the rest of the chip read/write.

It’s just that, if you do write-protect zones with a password, don’t forget the password :slight_smile:

One word of advice: if you’ve already used another app to set the “real” password in E5, don’t use the DT app, else you might mess up the chip forever. See here.

The DT app, as it is today, should be run first thing if you want it to have any chance to succeed all the way and not leave your chip half-configured.

Ok so that “write-protects certain critical sectors” is something I do with the DT app, not something that’s done by DT when they build these? Or is that already done and all I’d be doing is write-protecting the stuff that I add, the “user” space?

Oh, and… when setting the password in the DT app, do you do it in ASCII, or in hex? “NExT” or “4E 45 78 54” or “0x4E 0x45 0x78 0x54” or will it accept any of those?

Unhelpfully, It’s 4 ASCII letters encoded into a 32-bit word, big-endian - so “ABCD” makes a password value of 0x41424344.

It might have been done already.

EDIT: Actually, it probably was done already: I see 00 00 7F BD in E2. If the chip was vanilla, there’d be 00 00 00 BD there.

If it was done before your chip left the DT megafactory, the DT app will simply fail. It won’t touch the writeable userspace.

xNT needs to be protected, NExT is already protected from factory, for the new flexNExT and large format implants I think it’s some of each, and not sure on flexNT.

Bottom line, you don’t really need to worry about it, it’s already protected to stop accidental problems - just don’t tell any app the password unless you want it to change configuration because then it could cause issues. You can read and write the NDEF records without a password so use restraint and don’t tell any app what it is.

Changing the password from the default only further protects you from malicious changes. I.e. @anon3825968 knows your password is NExT, you pass out first at the party, he changes the link to pornhub and changes AUTH0 to 00, and changes the password so you can’t update the link. He’ll sell you the password for a case of beer! If this isn’t in your threat model, just leave it then you won’t forget it


I had to do up my doNExT. It was vanilla. Did it by hand though - safer.

Hmm, I think I have lost control of the story. Joke’s on me now :slight_smile:


First example that came to mind, thank you for your services to community education :slightly_smiling_face:

1 Like