Untung Anda menyebutkan poin terakhir dalam tanda kurung, karena itu meyakinkan saya. ;-P

@TX dan saya berdiskusi besar-besaran tentang menempatkan bagian-bagian konfigurasi di Halaman Status di IRC dan saya masih sangat tidak nyaman membuat halaman status baca-tulis dan berbasis skrip (karena, Anda tahu, ini membuka kemungkinan lubang keamanan). Dan saya masih melihat masalah terbesar di "kata sandi": Orang-orang akan secara membabi buta memasukkan kata sandi mereka yang biasa di sana, tidak peduli seberapa besar, gemuk, tebal, dan berkedip peringatannya adalah untuk tidak melakukannya. Dan pengaturan codeword benar-benar harus ke mode ahli, saya pikir.

Jika ini diterapkan, mungkinkah mengimplementasikan otentikasi menggunakan HTTP Digest? Dengan cara itu penyerang harus menggunakan MITM alih-alih mengendus biasa.

Ya, saya setuju dengan masalah alur kerja. Dan pendapat saya adalah bahwa ini adalah solusi ciuman yang cukup. Tapi tetap saja pengguna perlu mencari tahu alamat ip node untuk mengakses antarmuka. Jadi saya mengusulkan kita harus menampilkan kemungkinan tautan http ipv6 di halaman terakhir wizard router.

Namun perlu diperhatikan, penerapan fitur ini akan menimbulkan keluhan lain tentang fitur X yang harus dapat diakses dengan cara yang sama. Dan pendapat saya adalah bahwa kita tidak boleh melempar batu ke arah pengguna, tetapi juga pengguna yang menginstal teknologi harus menyadarinya dan mampu mengelolanya. Apalagi jika itu adalah pemasangan atap outdoor.

Terkompresi: Terapkan, tetapi siapkan argumen Anda.

Intisari HTTP

Saya ingin menggunakan otentikasi berbasis intisari. Sayangnya, uhttpd tidak mendukungnya.

Masalah Keamanan / injeksi kode

Saya yakin kami dapat menanganinya dengan baik. Saya belum pernah mendengar masalah injeksi kode dengan luci jadi mungkin hanya ada beberapa masalah. Kami juga dapat menjalankan fuzzer untuk mengujinya.

Kata sandi / Kata sandi pengguna

Kita dapat membuat field input pada configmode menjadi field normal (yaitu tanpa bintang) dan kita pasti harus menambahkan penjelasan singkat, namun ringkas tentang risiko keamanan dan, sekali lagi, mencegah pengguna menyetel codeword sama sekali.

Jika mereka masih memasukkan kata sandi standar mereka, tidak banyak yang bisa kami lakukan dan mereka tetap dalam masalah.

Tautan ke simpul

Ini memang masalah yang belum terpecahkan. Saya dapat membayangkan menampilkan alamat IPv6 simpul tepat di bawah bidang masukan kata sandi, seperti: "Bookmark [tautan] ini untuk mengubah koordinat simpul Anda setelah dijalankan."

Lainnya, permintaan fitur serupa

Saya sengaja membahas ini sangat sangat sempit karena saya mengetahui pertanyaan-pertanyaan lain itu. Tujuan lebih besar yang masih ingin saya capai adalah menyingkirkan configmode dan melakukan semuanya selama operasi normal, dari jarak jauh melintasi mesh. Namun, agar ini aman, kami memiliki banyak masalah untuk dipecahkan.

Jika seseorang meminta fitur serupa, kami harus mengarahkannya ke masalah ini atau halaman wiki yang merangkum semuanya. Dalam kedua kasus tersebut, kita harus memintanya untuk menulis masalah komprehensif tentang fitur yang diinginkan yang menangani semua masalah keamanan yang disebutkan di sini dan dalam diskusi yang dia lakukan dengan pengembang lain. Jika dia berhasil, dia mungkin memang memiliki poin yang valid.

Kata sandi satu kali

Saya baru saja mendapat ide lain, tetapi saya tidak ingin membahasnya di sini, karena dapat mengganggu alur kerja terlalu banyak. Kami pasti akan membahasnya setelah solusi saya saat ini diterima atau ditolak.

Codeword bisa untuk sekali pakai. Misal yang pertama mengubah koordinat (pada halaman status) dan memasukkan codeword yang benar berhasil. Setelah itu, itu terkunci dan kata sandi lain harus diatur dalam configmode.

Ini dapat dibuat opsional tetapi saya khawatir itu akan membuat configmode menjadi kompleks lagi (2 kotak centang, 3 bidang input untuk mengatur koordinat).

Bukankah intisari HTTP juga dapat diimplementasikan dalam skrip di belakang uhttpd? Lagi pula, itu hanya tajuk dan semacamnya ...

Saya pasti memilih untuk tidak mengimplementasikan ini untuk rilis gluon pertama. Kami menolak membuat halaman status menjadi lebih bagus, yang merupakan perubahan yang relatif tidak penting, jadi kami tidak harus membuang tumpukan pertanyaan ini untuk putaran pertama, saya pikir.

Itu tidak ditandai dengan tonggak sejarah jadi itu jelas bukan showstopper untuk 2014.1, namun jika kita setuju untuk membangunnya, itu mungkin membuatnya menjadi 2014.1.

Ya kau benar. Intisari HTTP dapat diimplementasikan hanya dengan menggunakan header.

Kembali ke otentikasi berbasis kata sandi untuk apa pun tampak seperti lompatan besar ke belakang bagi saya.

Saya pikir kami sudah memiliki solusi untuk masalah peta? Hampir semua pengguna berada dalam WLAN saat mengatur node mereka, jadi kami hanya dapat memuat peta dari internet. Kami hanya perlu menyediakan fallback (bidang input) yang baik untuk kasus ketika tidak.

Dan saya tidak melihat masalah dengan pengguna yang harus kembali ke mode konfigurasi sekali ketika mereka menginstal node di suatu tempat.

Opsi lain mungkin membuat halaman konfigurasi khusus dapat diakses menggunakan tunneling terbalik SSH. Ini akan mengharuskan pengguna untuk menyediakan kunci publik SSH-nya selama configmode.

Mengapa tidak memiliki halaman konfigurasi khusus yang dapat diakses melalui http://node.ffhh ketika node pertama kali terhubung ke jaringan freifunk (melalui mesh atau vpn). jika pemilik tidak mengunjungi mode konfigurasi, freifunk tidak akan berfungsi. mungkin dengan tombol reset sebagai semacam otentikasi ("tekan tombol html ini dan tombol reset dalam waktu 30 detik untuk memungkinkan konfigurasi node").

Saya memikirkannya sebagai semacam pengaturan plug and play dengan pendaftaran otomatis node pada boot pertama. koneksi otomatis ke jaringan freifunk (mesh atau vpn) akan memungkinkan untuk menampilkan peta dan sebagainya.

Saya tidak berpikir bahwa beberapa interaksi perangkat keras dimungkinkan jika node sudah berada di lokasi yang jauh. Juga untuk perangkat, misalnya perangkat ubnt, mengakses tombol perangkat keras agak sulit.
Alih-alih beberapa antarmuka http langsung, kita harus mempertimbangkan antarmuka konfigurasi berbasis ssh.
Yang kemudian dapat diakses melalui antarmuka aman https pihak ketiga.
Menerapkan antarmuka konfigurasi ssh memerlukan pengguna dengan shell konfigurasi khusus,
yang seharusnya tidak memungkinkan interaksi lain.

Ada solusi sekarang? Apakah seseorang sudah menerapkan sesuatu seperti ini secara lokal?

hexa datang dengan ide menggunakan OTP berbasis waktu (yaitu RFC 6238) untuk otentikasi. Saya agak suka pendekatan itu. Agar ini berfungsi, pengguna akan diperlihatkan kode QR (+string) untuk menyiapkan "Klien" OTP (yaitu ponsel cerdas). Pengguna harus dapat mengatur ulang token (atau menonaktifkan fitur sepenuhnya).

ini jauh dari ide yang mudah untuk mengatur geo dengan halaman status (dengan mode auth apa pun) .. tetapi jika Anda memiliki koneksi ssh dan Anda tidak takut dengan terminal - berikut adalah beberapa minisript yang membantu seperti lat lon alt location geoguess https:/ /github.com/viisauksena/gluon-banner/tree/master/files/usr/bin/ Anda dapat menambahkan secara default ke node atau firmware Anda

Bagaimana dengan petunjuk besar?

Pastikan Anda menuliskan koordinat geografis sebelum melanjutkan

yang akan ditampilkan hanya sekali pada panggilan pertama dari mode konfigurasi setelah instalasi baru?

@blocktrron @mweinelt @rotanid Bisakah kita menutup ini?

NeoRaider berkata

Dan saya tidak melihat masalah dengan pengguna yang harus kembali ke mode konfigurasi sekali ketika mereka menginstal node di suatu tempat.

Saya rasa ini benar... Kembali ke mode konfigurasi adalah mungkin. Tidak diperlukan solusi yang terlalu rumit di sini dan ini tidak diterapkan dalam 5 tahun. Jadi ini mungkin tidak akan pernah selesai...