phantom wallet extension<\/a> mehrere Konten erstellt, passiert intern folgendes: Jedes Konto erh\u00e4lt einen eindeutigen Identifier (oft eine Ableitung der \u00f6ffentlichen Adresse oder ein interner Index), eine Kategorie (Solana, Ethereum, Polygon usw.) und einen optionalen Namen. Die private Key-Ableitung folgt einem Standard-Derivationspfad (wie BIP44 f\u00fcr Ethereum oder Solanas Derivationsstandard). Das erlaubt es, dass ein einzelner Konto-Eintrag Adressen auf mehreren Blockchains generieren kann \u2013 beispielsweise ein Phantom-Konto, das gleichzeitig eine Solana-Adresse und eine Ethereum-Adresse hat.<\/p>\nDieser Aufbau ist bewusst gew\u00e4hlt. Er erm\u00f6glicht Nutzern, konzeptionell getrennte Verm\u00f6gensbest\u00e4nde unter einem Passwort zu verwalten, ohne dass mehrere Recovery-Prozesse erforderlich sind. Gleichzeitig bedeutet es aber auch, dass der Schutz des Passworts und der lokalen Speicherung entscheidend ist. Wenn die Extension-Datenbank auf dem Ger\u00e4t kompromittiert wird \u2013 etwa durch Malware mit Browserzugriff \u2013 kann ein einzelner Datenbankzugriff alle Konten und Seeds offenbaren.<\/p>\n
Kontoschalter-Sicherheit und die Rolle des Passworts<\/h2>\n
Das Dropdown-Men\u00fc zum Wechsel zwischen Konten ist eine Benutzeroberfl\u00e4chen-Conveniance, die aber auf einer kritischen Abh\u00e4ngigkeit ruht: Das Hauptpasswort. Solange ein Nutzer in der Extension angemeldet bleibt, kann er zwischen Konten wechseln, ohne sich erneut authentifizieren zu m\u00fcssen. Das ist f\u00fcr t\u00e4gliche Nutzung praktisch, bedeutet aber auch, dass jede Person mit physischem Zugriff auf den entsperrten Browser oder das Ger\u00e4t alle sichtbaren Konten nutzen kann.<\/p>\n
Phantom Wallet Chrome und andere Browser-Extensions haben hier einen Vorteil gegen\u00fcber mobilen Apps: Der Browser selbst kann eine zus\u00e4tzliche Schutzschicht bieten, wenn das Betriebssystem durch Hardware-Schl\u00fcsselspeicher oder biometrische Authentifizierung gesch\u00fctzt ist. Allerdings ist die Browser-Sperren nicht standardisiert. Wenn Chrome nicht geschlossen wird und die Session offen bleibt, reicht ein physischer Zugriff, um Transaktionen zu signieren.<\/p>\n
Eine h\u00e4ufige Fehlvermutung ist, dass mehrere Konten in einer Extension bedeutet, dass jedes Konto sein eigenes Passwort h\u00e4tte. Das ist nicht der Fall. Phantom nutzt ein einziges Passwort f\u00fcr die gesamte Extension. Der Vorteil: Nutzer m\u00fcssen sich nicht mehrere Passw\u00f6rter merken. Der Nachteil: Wenn das Passwort schwach ist oder gehashed wurde, sind alle Konten betroffen. Eine St\u00e4rke des Passworts muss daher alle Konten sch\u00fctzen, nicht nur eines.<\/p>\n
Ein bew\u00e4hrter Ansatz ist, das Hauptpasswort nicht nur lang und komplex zu w\u00e4hlen, sondern auch die Session-Verwaltung zu nutzen. Phantom bietet die Option, die Extension nach einer bestimmten Zeit ohne Aktivit\u00e4t automatisch zu sperren. Das reduziert das Risiko, dass ein kurzzeitig verlassener Rechner missbraucht wird. Der Nachteil ist, dass h\u00e4ufiges Entsperren l\u00e4stig sein kann \u2013 das ist ein klassischer Sicherheits-Komfort-Tradeoff, den jeder Nutzer selbst bewerten muss.<\/p>\n
Best Practices f\u00fcr die Verwaltung mehrerer Seeds<\/h2>\n
Wenn ein Nutzer mehrere Seed-Phrasen in einer Phantom Extension verwalt, sollte er zun\u00e4chst verstehen, dass jede Seed-Phrase vollst\u00e4ndigen Zugriff auf alle mit ihr verbundenen Keys gew\u00e4hrt. Eine 12- oder 24-Wort-Phrase ist nicht einfach ein Passwort \u2013 sie ist ein vollst\u00e4ndiger Sicherungsschl\u00fcssel. Wenn diese Phrase an nur einer Stelle unsicher gespeichert wird (etwa im Cloud-Speicher oder in einer E-Mail-Nachricht), ist das gesamte Konto kompromittiert, unabh\u00e4ngig davon, wie sicher das Browser-Passwort ist.<\/p>\n
Die erste Best Practice ist daher die r\u00e4umliche Trennung: Mehrere Seeds sollten an verschiedenen physischen Orten oder in verschiedenen Verwahrmethoden aufbewahrt werden. Ein Szenario k\u00f6nnte aussehen wie: Konto 1 (t\u00e4glich genutzte DeFi-Transaktionen) in der aktiven Browser-Extension, mit Seed-Phrase auf Papier im Heim-Safe. Konto 2 (Langzeit-NFT-Bestand) mit Seed-Phrase auf einem zweiten Blatt Papier an einem anderen Ort oder in einem Tresor. Konto 3 (Testnetz-Experimente mit kleinen Betr\u00e4gen) mit Seed-Phrase in einem verschl\u00fcsselten Passwort-Manager, der separat gesichert ist.<\/p>\n
Die zweite Best Practice ist die Benennung. Phantom erlaubt es, Konten mit eigenen Namen zu versehen. Ein Fehler ist, generische Namen wie \u201eKonto 1″, \u201eKonto 2″ zu verwenden. Besser sind beschreibende Namen wie \u201eSolana DeFi Main”, \u201eEthereum NFT Vault”, \u201ePolygon Test Txns”. Diese Namen sind nicht verschl\u00fcsselt und stehen in der lokalen Extension-Datenbank \u2013 sie sind also ein Anhaltspunkt, aber kein Secret. Mit aussagekr\u00e4ftigen Namen sinkt die Wahrscheinlichkeit, dass ein Nutzer aus Versehen an das falsche Konto sendet.<\/p>\n
Die dritte Best Practice ist ein Testprotokoll. Bevor an ein neues oder lange nicht genutztes Konto ein signifikanter Betrag transferiert wird, sollte ein Testbetrag (z. B. 1 Dollar oder \u00e4quivalent in Token) gesendet werden. Das best\u00e4tigt, dass (1) die Adresse korrekt ist, (2) das Konto aktiv und erreichbar ist, (3) der Nutzer die richtige Blockchain gew\u00e4hlt hat und (4) die Geb\u00fchren und Netzwerkbest\u00e4tigungen wie erwartet funktionieren. Dieser einfache Schritt verhindert Fehler wie Doppelbuchungen oder Transfers auf verkehrte Adressen.<\/p>\n
Abh\u00e4ngigkeiten und Angriffsvektoren beim Kontowechsel<\/h2>\n
Der Kontoschalter der Phantom Wallet Extension ist selbst nicht komplex, aber die Abh\u00e4ngigkeiten darum herum sind es. Wenn ein Nutzer ein Konto wechselt, passieren mehrere Dinge gleichzeitig: (1) Die UI zeigt die \u00f6ffentliche Adresse des neuen Kontos, (2) die Extension signiert die n\u00e4chste Transaktion mit dem privaten Key dieses Kontos, (3) ein verbundener dApp (etwa eine Decentralized Exchange) registriert m\u00f6glicherweise einen Account-Wechsel und aktualisiert sein Interface.<\/p>\n
Ein h\u00e4ufiger Fehler entsteht, wenn ein Nutzer schnell zwischen Konten wechselt und dann eine Transaktion best\u00e4tigt, ohne zu \u00fcberpr\u00fcfen, welches Konto gerade aktiv ist. Die Phantom-Extension zeigt die aktive Adresse an, aber in Eile oder unter Ablenkung \u00fcbersieht ein Nutzer leicht Details wie die letzten vier Zeichen der Adresse. Ein Angreifer k\u00f6nnte diese Unaufmerksamkeit ausnutzen, indem er etwa eine dApp-Seite manipuliert (Man-in-the-Middle-Angriff auf unsicherer Verbindung) und ein Konto vort\u00e4uscht, das nicht das Zielkonto ist.<\/p>\n
Ein zweiter Angriffsvektor ist die Browser-Session. Wenn ein Nutzer mehrere Browser-Fenster oder Tabs mit unterschiedlichen dApps offen hat, kann es sein, dass ein Tab eine alte Adresse zwischenspeichert. Wenn der Nutzer dann in einem anderen Tab das Konto wechselt, aber in den ersten Tab zur\u00fcck wechselt, ohne die Seite neu zu laden, arbeitet die dApp m\u00f6glicherweise mit veralteten Adressinformationen. Das kann zu Transaktionen f\u00fchren, die beabsichtigte Ziele verfehlen.<\/p>\n
Ein dritter Vektor ist die Gasgeb\u00fchren-Manipulation. Ein kompromittierter dApp-Server k\u00f6nnte \u2013 nachdem der Nutzer den Account wechselt \u2013 absichtlich extreme Gasgeb\u00fchren vorschlagen und hoffen, dass der Nutzer die Best\u00e4tigungsschirme nicht sorgf\u00e4ltig liest. Phantom warnt vor ungew\u00f6hnlich hohen Geb\u00fchren, aber die Warnung kann auch als falsch positiv \u00fcbersehen werden, wenn es legitime Gr\u00fcnde f\u00fcr hohe Geb\u00fchren gibt (etwa bei \u00dcberlastung des Netzwerks).<\/p>\n
Technische Sicherheit der lokalen Verschl\u00fcsselung<\/h2>\n
Phantom speichert Seeds und Private Keys nicht im Klartext. Die Daten werden lokal mit AES-Verschl\u00fcsselung und unter Nutzung des Nutzer-Passworts als Hauptschl\u00fcssel (oder einer Ableitung davon) verschl\u00fcsselt. Das bedeutet: Selbst wenn jemand Zugriff auf die Browser-Extension-Dateien hat (etwa auf dem Dateisystem des Computers), kann er die Keys ohne das Passwort nicht direkt auslesen.<\/p>\n
Allerdings gibt es in dieser Sicherheitskette mehrere Punkte, wo die Verschl\u00fcsselung durch andere Vektoren umgangen werden kann. Der erste ist der RAM. Wenn die Extension l\u00e4dt und den verschl\u00fcsselten Speicher entschl\u00fcsselt, sitzen die unverschl\u00fcsselten Keys kurzzeitig im Arbeitsspeicher. Ein Kernel-Level-Malware-Programm oder ein Kalt-Start-Angriff (Freezing von RAM, dann Auslesen ohne Neustart) k\u00f6nnte diese Keys potenziell extrahieren. Das ist ein theoretisches Risiko f\u00fcr die Mehrzahl der Nutzer, aber ein reales Risiko f\u00fcr hochwertige Ziele (etwa B\u00f6rsen-Betreiber oder gro\u00dfe Investoren).<\/p>\n
Der zweite Punkt ist der Browser selbst. Wenn der Browser gehackt wird oder eine Extension mit Malware installiert wird, kann diese das Passwort aufzeichnen, wenn es eingegeben wird, oder die bereits entschl\u00fcsselten Keys auslesen, w\u00e4hrend die Session aktiv ist. Phantom kann dies nicht vollst\u00e4ndig verhindern \u2013 es ist eine generische Limitation jeder Browser-Extension. Die Mitigation ist, das System sauber zu halten, regelm\u00e4\u00dfig Updates durchzuf\u00fchren und nur vertraute Extensions zu installieren.<\/p>\n
Der dritte Punkt ist das Betriebssystem. Windows, macOS und Linux k\u00f6nnen jeweils unterschiedliche Sicherheitslevels bieten. macOS mit M1-Chip und Secure Enclave hat Vorteile gegen\u00fcber \u00e4lteren Windows-Installationen ohne TPM. Phantom kann dies nicht kontrollieren \u2013 der Nutzer muss sein System selbst sichern. Eine moderne Linux-Distribution mit SELinux oder AppArmor kann zus\u00e4tzliche Isolation bieten, erfordert aber mehr Konfiguration.<\/p>\n
Synchronisation \u00fcber Ger\u00e4te und zus\u00e4tzliche Komplexit\u00e4t<\/h2>\n
Phantom bietet die M\u00f6glichkeit, ein Konto \u00fcber mehrere Ger\u00e4te zu synchronisieren. Das funktioniert \u00fcber einen Cloud-Backup-Mechanismus: Der Nutzer erstellt einen Backup-Code (einen zuf\u00e4lligen String), der mit seinen Konten verkn\u00fcpft ist. Auf einem neuen Ger\u00e4t kann der Nutzer diesen Code eingeben und erh\u00e4lt die Konten zur\u00fcck \u2013 ohne die Seed-Phrasen manuell eingeben zu m\u00fcssen.<\/p>\n
Das ist praktisch, erh\u00f6ht aber die Angriffsoberfl\u00e4che. Der Backup-Code wird wahrscheinlich in einem Cloud-Service gespeichert (etwa bei Phantom selbst oder \u00fcber einen Drittanbieter). Wenn dieser Service kompromittiert wird oder ein Angreifer den Backup-Code abf\u00e4ngt, k\u00f6nnte er auf einem neuen Ger\u00e4t alle Konten herunterladen. Phantom versucht, dies durch zus\u00e4tzliche Authentifizierungsschritte zu mitigieren (etwa durch E-Mail-Best\u00e4tigung), aber das Risiko bleibt.<\/p>\n
Die beste Praktik ist daher, den Backup-Code wie eine zweite Seed-Phrase zu behandeln: Sicher aufbewahren, nicht digital speichern, und nur nutzen, wenn ein Ger\u00e4te wirklich verloren oder zerst\u00f6rt wurde. Viele Nutzer untersch\u00e4tzen die Sicherheit des Backup-Codes und speichern ihn im Cloud-Drive oder in einem Online-Passwort-Manager, was das Risiko stark erh\u00f6ht.<\/p>\n
Checkliste f\u00fcr sichere Verwaltung mehrerer Konten<\/h2>\n
Ein systematisches Vorgehen reduziert Fehler. Die erste Aufgabe ist eine Inventory: Welche Konten braucht der Nutzer wirklich? Wenn die Antwort \u201eacht verschiedene DeFi-Konten und sechs NFT-Konten” ist, ist das ein Zeichen, dass eine einzelne Wallet m\u00f6glicherweise zu viel Komplexit\u00e4t tr\u00e4gt. Es kann sicherer sein, ein Konto f\u00fcr h\u00e4ufig genutzte Transaktionen zu reservieren und andere Konten in zus\u00e4tzlichen Browser-Profilen oder sogar auf separaten Hardware-Wallets zu verwalten.<\/p>\n
Die zweite Aufgabe ist die Dokumentation. Jedes Konto sollte dokumentiert sein: Sein Name, sein Verwendungszweck, wof\u00fcr die Seed-Phrase ist, wo sie aufbewahrt wird und wer Zugriff hat (falls mehrere Personen oder eine Erbschaft relevant ist). Diese Dokumentation sollte selbst verschl\u00fcsselt und an sicherer Stelle aufbewahrt werden.<\/p>\n
Die dritte Aufgabe ist ein Testplan. Vor dem Echtbetrieb sollte jedes Konto mit kleinen Testbetr\u00e4gen auf einem Testnetz oder mit einer Testtransaktion validiert werden. Dazu geh\u00f6rt auch, die Recovery zu testen: Der Nutzer sollte mindestens einmal \u00fcben, eine Seed-Phrase wiederherzustellen, um sicherzustellen, dass er die Seed-Phrase korrekt aufgeschrieben hat und dass der Recovery-Prozess funktioniert, falls es je erforderlich ist.<\/p>\n
Die vierte Aufgabe ist ein Passwort-Regime. Das Hauptpasswort sollte stark sein (mindestens 16 Zeichen, Mischung aus Gro\u00df- und Kleinbuchstaben, Zahlen, Sonderzeichen), und der Nutzer sollte es nirgendwo aufschreiben, sondern in seinem biologischen Ged\u00e4chtnis behalten oder in einem lokalen (nicht Cloud-gest\u00fctzten) Passwort-Manager speichern. Falls der Nutzer das Passwort vergisst, kann es nur durch Recovery aus einer Seed-Phrase wiederhergestellt werden \u2013 und das ist ein aufw\u00e4ndiger Prozess.<\/p>\n
Die f\u00fcnfte Aufgabe ist eine periodische \u00dcberpr\u00fcfung. Alle sechs Monate sollte ein Nutzer \u00fcberpr\u00fcfen: Welche Konten nutze ich noch wirklich? Sind die Adressen noch korrekt? Haben sich die Seed-Phrase-Lagerungsorte ver\u00e4ndert? Gibt es Hinweise auf unbefugten Zugriff (etwa Transaktionen, die ich nicht autorisiert habe)? Diese \u00dcberpr\u00fcfung ist Wartung, keine Paranoia.<\/p>\n
Migration und Kontoaufl\u00f6sung<\/h2>\n
Wenn ein Nutzer ein Konto aus der Phantom Extension l\u00f6schen m\u00f6chte, muss er zun\u00e4chst sicherstellen, dass keine Gelder mehr darauf sind. Es ist m\u00f6glich, aber potenziell teuer, Token von einer gel\u00f6schten Adresse wiederherzustellen (etwa indem man die Seed-Phrase in ein anderes Wallet importiert). Der sicherere Weg ist, zuerst alle Token und NFTs auf andere Konten zu transferieren, dann das Konto zu l\u00f6schen.<\/p>\n
Migration zwischen Wallets (etwa von Phantom zu einer Hardware-Wallet oder zu einem anderen Self-Custody-Anbieter) sollte schrittweise erfolgen. Der Nutzer sollte nicht alle Konten auf einmal migrieren. Besser ist es, ein Test-Konto zu w\u00e4hlen, die Migration zu \u00fcben, die Seeds zu \u00fcberpr\u00fcfen und erst dann die restlichen Konten zu migrieren. Das reduziert das Risiko, dass alle Konten auf einmal aus der aktiven Verwaltung verschwinden, falls ein Fehler auftritt.<\/p>\n
Ein h\u00e4ufiger Fehler ist, die alte Seed-Phrase sofort zu l\u00f6schen, nachdem ein Konto in eine neue Wallet importiert wurde. Besser ist es, die alte Phrase noch mindestens eine Woche aufzubewahren, w\u00e4hrend man verifiziert, dass die neue Wallet das Konto korrekt anzeigt und alle Transaktionen auf der neuen Wallet funktionieren. Erst dann sollte die alte Phrase sicher gel\u00f6scht werden.<\/p>\n
\n
H\u00e4ufig gestellte Fragen<\/h2>\n\n
Kann ich mehrere Konten in einer Phantom Wallet Extension haben, ohne mehrere Passw\u00f6rter zu ben\u00f6tigen?<\/h3>\n
Ja. Phantom nutzt ein einziges Hauptpasswort, das alle Konten sch\u00fctzt. Jedes Konto ist mit einer eigenen Seed-Phrase oder einem privaten Schl\u00fcssel verbunden, aber die Authentifizierung f\u00fcr die Extension erfolgt \u00fcber das eine Passwort. Das ist praktisch, bedeutet aber auch, dass die St\u00e4rke dieses Passworts alle Konten sch\u00fctzen muss.<\/p>\n<\/p><\/div>\n
\n
Was passiert, wenn mein Hauptpasswort kompromittiert wird, wenn mehrere Konten in der Phantom Wallet Extension aktiv sind?<\/h3>\n
Ein Angreifer mit dem korrekten Passwort kann alle Konten in der Extension einsehen und Transaktionen von jedem autorisieren. Deshalb ist ein starkes, eindeutiges Passwort essentiell. Falls ein Passwort kompromittiert wird, sollte sofort (1) alle Konten inspiziert werden, (2) Tokens auf sichere externe Adressen transferiert werden, falls vorhanden, und (3) die Extension aus dem Browser entfernt und neu installiert werden, nachdem alle Gelder gesichert sind.<\/p>\n<\/p><\/div>\n
\n
Ist es sicherer, mehrere separate Browser-Extensions zu nutzen statt mehrere Konten in einer Extension?<\/h3>\n
Das h\u00e4ngt von der Nutzungsform ab. Separate Instanzen bieten bessere Isolation \u2013 ein kompromittiertes Konto betrifft nicht die anderen. Der Nachteil ist erh\u00f6hte Komplexit\u00e4t und mehrere Passw\u00f6rter, die verwirrt oder schwach gemacht werden k\u00f6nnen. F\u00fcr Nutzer mit sehr hohem Verm\u00f6gen oder Sicherheitsanforderungen ist Isolation sinnvoll. F\u00fcr die meisten Nutzer ist ein starkes Passwort und gutes Benennungsschema in einer einzigen Extension ausreichend.<\/p>\n<\/p><\/div>\n<\/div>\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
Ein Web3-Nutzer arbe […]<\/p>\n","protected":false},"author":6,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[1],"tags":[],"class_list":["post-11142","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.mlwf.org.tw\/index.php\/wp-json\/wp\/v2\/posts\/11142","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.mlwf.org.tw\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.mlwf.org.tw\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.mlwf.org.tw\/index.php\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/www.mlwf.org.tw\/index.php\/wp-json\/wp\/v2\/comments?post=11142"}],"version-history":[{"count":1,"href":"https:\/\/www.mlwf.org.tw\/index.php\/wp-json\/wp\/v2\/posts\/11142\/revisions"}],"predecessor-version":[{"id":11143,"href":"https:\/\/www.mlwf.org.tw\/index.php\/wp-json\/wp\/v2\/posts\/11142\/revisions\/11143"}],"wp:attachment":[{"href":"https:\/\/www.mlwf.org.tw\/index.php\/wp-json\/wp\/v2\/media?parent=11142"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.mlwf.org.tw\/index.php\/wp-json\/wp\/v2\/categories?post=11142"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.mlwf.org.tw\/index.php\/wp-json\/wp\/v2\/tags?post=11142"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}