Eufy 云端明文存储用户 Wi-Fi 密码，每次登录都会返回

If you own one of these: the device still works, but assume its cloud-side secrets (including your Wi-Fi password) are only as safe as your eufy account and eufy's servers. Put IoT cameras on a separate network/VLAN, use a Wi-Fi password you don't reuse anywhere, and turn on 2FA on your eufy account.

The HomeBase 3 is eufy's camera hub. It talks to the eufy cloud over an authenticated HTTPS API, and to the app over a peer-to-peer (P2P/PPCS) channel that can run locally or remotely via eufy's relay servers. I started with nothing but the hub's IP address and rebuilt the whole path a client takes, to see what an attacker with access to an account actually gets.

When the app lists your stations, the cloud returns a blob that contains, verbatim:

{ "ssid": "<your network>", "password": "<your Wi-Fi password, in clear text>", "security": "WPAPSKWPA2PSK/TKIPAES", "bssid": "<your router>" }

The connection is encrypted in transit, but the stored value is plaintext and it's returned on every login. Provisioning a camera only requires writing the Wi-Fi password to the hub — there is no reason the cloud needs to keep a readable copy and read it back to the app forever. A breach of eufy's servers, a rogue insider, or a single stolen account token exposes the Wi-Fi password of every affected home.

The same account API freely returns the hub's P2P ID, its P2P connection/relay strings, a "wake key," and even the HomeKit setup code. These are exactly the values needed to locate the hub and open a session to it (next section). Nothing device-side gates this — it's just there in the account data.

Commands to the hub are "encrypted," but here's how the key is built:

key = ( device_serial[-7:] + p2p_id[ fixed slice ] ) # 16 ASCII bytes AES-128, ECB mode, no IV

That's it. The serial number is printed on the device and the box. The P2P ID is handed out by the cloud API. There is no secret, no per-session randomness, and ECB mode means identical blocks encrypt identically. Anyone who knows those two public-ish strings can decrypt and forge the hub's "encrypted" commands. This is the kind of thing that's supposed to protect a camera that watches your living room.

Opening an authenticated P2P session needs only the P2P ID and a key (DSK) that the cloud will issue to any valid account token. No device-held secret. No "approve this device" prompt. And because it rides eufy's relay, it works from anywhere, not just your LAN.

Once in, I sent the hub command after command. It answered all of them with no per-command authorization — just the fact that I had a session was enough — and happily streamed hundreds of kilobytes of its own configuration back to me.

(During testing the P2P channel also went silent after a batch of setting-change commands and then recovered on reconnect — a possible denial-of-service I haven't fully isolated. Flagging it honestly rather than overselling it.)

Credit where due: the hub's RTSP stream (/live0) is properly protected with Digest authentication and a random challenge per request. No unauthenticated video, no trivial replay. So they can do auth correctly — which makes items 1–4 more disappointing, not less.

I reported a closely related weakness in this same product line — weak encryption of locally stored recordings — to eufy's product-security team. Their first written response was that it was a known issue they would not fix, together with a request not to discuss it.

After this post went live, eufy/Anker re-engaged. They apologised, called the earlier "won't fix" an internal miscommunication, and now say a fix for that recordings issue is officially planned — though without a timeline yet. On the findings in this post, they've acknowledged the weak-cipher issue (they say newer code moved to AES-GCM, with some legacy ECB paths remaining) and are investigating the Wi-Fi-password exposure; I've given them the specifics to reproduce it. No fix or timeline has been committed for these yet.

The findings above were discovered independently, on my own hardware, and were never submitted to eufy's bounty program. I'm leaving the post up and will update it as fixes and timelines actually land — including the recordings fix, once there's a date.

Stop storing and returning the Wi-Fi PSK. Stop handing device secrets to every account session. Use a real per-device secret and an authenticated cipher (AES-GCM with per-session nonces), not ECB keyed from public data. Enforce per-command authorization. None of this is exotic — they already do Digest auth correctly on the RTSP side.

Responsible-use note: the technical detail here is enough to understand and verify the problem on your own device. I'm not releasing a turnkey exploit. Don't point any of this at hardware or accounts that aren't yours.