Solusi kunci lisensi dalam aplikasi web, apa pendekatan terbaik?

14

Saya bingung oleh permintaan dari manajer saya. Saya bekerja untuk startup kecil dan kami mengembangkan aplikasi web untuk tarif tetap dengan perjanjian pemeliharaan untuk perusahaan JAUH lebih besar. Mengetahui cerita-cerita horor tentang bagaimana perusahaan besar hanya akan membayar tagihan mereka sampai detik terakhir, kami memutuskan bahwa kami ingin melindungi diri sendiri dengan dapat melisensikan aplikasi web ini dengan cara bahwa jika kami tidak dibayar, perangkat lunak tidak lagi berfungsi.

Saya telah melihat ini dilakukan sebelumnya untuk aplikasi desktop namun ini akan menjadi aplikasi web yang akan mereka host secara internal dan tidak akan dapat diakses dari Internet.

Apa pendekatan terbaik untuk melakukan ini, kami ingin memiliki jejak kecil dan ingin kemampuan untuk memperbarui kunci lisensi yang telah mereka bagikan.

Adakah yang melakukan hal serupa? Apakah kita sepenuhnya keluar dari pikiran kita? Adakah yang punya saran yang lebih baik?

web-development licensing web-applications maple_shaft
sumber
Untuk melakukan ini dengan benar, Anda akan membutuhkan BANYAK waktu (atau mereka hanya akan merusaknya). Jauh lebih murah hanya dengan membeli produk yang dirancang untuk melindungi program java. Jika tidak, cukup buat lisensi sebagai potongan kode byte java yang dibaca oleh program dan kemudian aktifkan.
Itulah yang saya takutkan, saya akan mencari solusi pihak ketiga namun kami sudah terlalu berlebihan.
maple_shaft
Maka buatlah itu berjalan sangat lambat 2 minggu setelah pembayaran jatuh tempo.
@ Thorbjørn, LOL !! ^ _ ^ Proyek yang menggoda seperti ini adalah pemimpin yang merugi untuk mencoba dan menghidupkan bisnis tambahan dengan perusahaan ini. KUALITAS TERTINGGI adalah yang PALING penting. Pada saat yang sama kami tidak ingin benar-benar kacau saat kami mencari pot madu.
maple_shaft
@maple, terdengar seperti rencana bisnis yang buruk. Kemudian serahkan uang yang terkumpul ke akuntan dan jangan pertimbangkan mengirimkan malware.

Jawaban:

9

Ada banyak cara untuk mengimplementasikan sesuatu seperti ini, tetapi inilah yang seharusnya tidak terlalu sulit untuk dilakukan:

Anda memerlukan situs web yang tersedia untuk umum di suatu tempat yang meng-host file yang berisi hash kunci lisensi yang telah dimasukkan daftar hitam. Bagaimana Anda mengelola file ini terserah Anda, tetapi file itu sendiri hanya perlu memiliki hash per baris.

Kemudian, secara berulang, perangkat lunak Anda memulai pengunduhan file ini (sebagian besar bahasa sisi server menyediakan ini) dan kemudian mencari hash kunci lisensi yang diinstal. Jika ditemukan, maka aplikasi tahu bahwa itu harus mati sampai blacklist dihapus.

MD5 atau serupa ditambah rahasia harus cukup untuk ini. Anda bisa menjadi pelamun dan meminta aplikasi mengirimkan permintaan ke situs Anda dan mencarinya di database dengan cepat, tetapi file tersebut (untuk apa yang saya asumsikan semoga menjadi daftar pendek) mudah-mudahan tetap kecil dan mungkin cara termudah.

Bagian yang lebih sulit adalah menjaga aplikasi tetap mati. Bagaimanapun, Anda harus menyimpan ini di suatu tempat secara internal, yang berarti jika terlalu jelas itu bisa dengan mudah ditumbangkan, dan bahkan jika itu tidak terlalu jelas, itu dapat dengan mudah dikembalikan dengan mengembalikan tabel yang sesuai (s) / file. Karena itu saya menyarankan metode perlindungan kedua juga.

Metode ini akan menyimpan "LIVE" atau "MATI" (atau sesuatu yang cukup mirip) dalam tabel atau file, tetapi sekali lagi HASHed. Ini perlu diiris dengan garam Anda dan cap waktu. Setiap kali halaman aplikasi Anda berjalan, periksa nilai ini dengan versi hash "LIVE" + garam + cap waktu dan kemudian izinkan untuk rentang cap waktu yang valid (misalnya, satu hari, dua hari, satu minggu, satu bulan, dll. Perlu diingat semakin besar rentang performa yang lebih keras akan mendapatkan pukulan.). Selama semuanya cocok (atau kecocokan ditemukan), aplikasi itu hidup; jika tidak, bahkan jika nilai dalam file atau tabel khusus adalah "LIVE", itu masih akan mati jika ada upaya untuk memulihkan dari cadangan karena cap waktu akan berada di luar ambang Anda.

Singkatnya (ini mengasumsikan bahwa Anda memiliki beberapa metode programatik untuk memeriksa validitas kunci lisensi, seperti semacam checksum atau metode lain):

  • CheckBlacklist
    • Ubah Kunci Lisensi menjadi hash dengan garam
    • Minta file daftar hitam dari server
    • Apakah hash saya ada di file?
    • Jika YA, maka simpan hash "MATI" + garam + cap waktu (terpotong ke hari; tidak perlu menyimpan jam + hari + menit)
    • Jika TIDAK, maka simpan hash "LIVE" + garam + stempel waktu (terpotong)
  • IsKeyAlive
    • Buat hash dari "LIVE" + garam + cap waktu terpotong
    • Muat hash DeadAlive
    • Apakah mereka setuju?
    • Jika YA, maka kita hidup; mengembalikan TRUE.
    • Jika TIDAK, maka kita mungkin mati, tetapi kita mungkin masih berada dalam jendela timestamp kita:
      • Kurangi satu hari dari cap waktu dan ulangi hash.
      • Apakah kita setuju sekarang?
      • IYA? Kembalikan BENAR
      • Tambahkan satu hari ke cap waktu dan ulangi hash
      • Apakah kita setuju sekarang?
      • IYA? Kembalikan BENAR
    • Pada titik ini, kami berada di luar rentang cap waktu tanpa kecocokan. Kembalikan SALAH. (Bunuh aplikasi)

Sekarang, kebaikan tahu ada sejuta dan satu cara ini bisa gagal. Pertimbangkan semua cara yang mungkin dan bangun sistem yang andal (termasuk yang mengasumsikan klien benar jika file daftar hitam tidak dapat diunduh). Uji, uji, uji, dan uji lagi sebelum digunakan, karena jika salah, Anda akan kehilangan kepercayaan klien.

Kerri Shotts
sumber
+1 Untuk jawaban yang sangat rumit, O_o. Saya mungkin salah tetapi saya tidak berpikir ini perlu sesulit ini. Saya tidak mendistribusikan Microsoft Office, ini aplikasi yang dibuat khusus untuk satu klien. Masalah yang sama masih tetap ada di sini bahwa server yang menampung aplikasi ini mungkin tidak dapat berkomunikasi dengan layanan eksternal. Saya tidak mengerti mengapa enkripsi, hash, dan garam sangat diperlukan di sini. Yang benar-benar kita inginkan adalah saklar mematikan.
maple_shaft
Terima kasih ;-) Alasan saya menyarankan menggunakan hash adalah agar tidak ada orang yang mengendus lalu lintas dan / atau melihat kode / tabel / file di klien Anda dapat mengetahui apa yang sedang terjadi di dunia. Hash tidak berarti apa-apa tanpa kedua belah pihak terlibat di dalamnya, dan klien tidak mungkin memahami bahwa hash sebenarnya merupakan representasi dari kunci lisensi mereka. (Jika ditransmisikan secara jelas, mereka akan langsung tahu.) Demikian juga mengurangi kebutuhan untuk melakukan enkripsi atau SSL pada file daftar hitam Anda - hash dengan sendirinya berarti zip.
Kerri Shotts
Catatan: jika Anda percaya bahwa klien akan menganggap bahwa pengembalian tabel / file tertentu terlalu sulit, Anda dapat sedikit mengurangi kerumitan dengan menghapus centang setiap kali aplikasi dijalankan. Yang mengatakan, tidak akan butuh seseorang terlalu lama untuk mencari tahu apa yang sedang terjadi dan mencari jalan keluar.
Kerri Shotts
1
CheckBlacklist: license-server.example.com: no route to hostSekarang apa? Server lisensi mungkin bahkan tidak ada di masa depan - dan jangan bilang bahwa perusahaan Anda akan tetap hidup dalam dua puluh tahun, itu agak tidak mungkin secara statistik.
Piskvor meninggalkan gedung
1
Ada banyak cara untuk mengatasi ini, termasuk tidak menggunakan server Anda sendiri. Gunakan Amazon atau Google atau semacamnya. Atau, buat "kepercayaan" pada cek sehingga jika tuan rumah mati pengguna dapat terus menggunakan aplikasi. Seperti yang saya sebutkan di posting, ada sejuta cara yang bisa gagal, dan itulah sebabnya saya menentang pemeriksaan semacam ini. Saya lebih suka mempercayai pelanggan saya daripada menghasilkan cek semacam ini. (Kunci lisensi sendiri, saya akan pilih. Tapi memasukkannya ke daftar hitam? Tidak sebanding dengan usahanya, IMO.)
Kerri Shotts
4

Jawaban lain telah melakukan pekerjaan yang baik untuk meliput sisi teknis. Tapi tolong pertimbangkan sisi hukumnya.

Apakah Anda bahkan memiliki hak untuk memblokir aplikasi mereka jika mereka tidak membayar? Jika Anda tidak menyebutkan ini sebelumnya dalam kontrak, Anda mungkin tidak memiliki hak untuk melakukannya, bahkan jika pembayaran lewat (seperti Anda tidak selalu berhak untuk mengambil kembali sesuatu yang Anda jual). Juga, banyak negara memiliki undang-undang khusus yang melarang "manipulasi program komputer" - apa yang Anda lakukan mungkin dianggap seperti itu dan bahkan dapat membuat Anda terkena pertanggungjawaban pidana.

Jadi saya sarankan untuk mendiskusikan hal ini dengan seorang pengacara terlebih dahulu, untuk menghindari masuk ke dalam air panas.

Pada akhirnya, mungkin lebih baik hanya mengandalkan sistem hukum. Jika mereka tidak membayar, bernegosiasi, dan jika itu tidak membantu, tuntut saja. Di banyak negara, tuntutan relatif tidak menyakitkan & murah jika situasi kontraknya jelas (di Jerman misalnya Anda bisa mendapatkan Mahnbescheid dengan harga kurang dari 20 €).

sleske
sumber
Ini semacam ikatan dalam menjawab pertanyaan saya tentang apakah kita gila. Saya mendapat kesan berbeda bahwa saya tidak punya pilihan dan ini adalah sesuatu yang ditekankan oleh atasan saya meskipun itu tidak ada dalam kontrak. Sayangnya saya tinggal dan bekerja di AS di mana Anda tidak dapat mengambil perusahaan besar bahkan jika Anda benar. Mereka memiliki pasukan pengacara yang akan mengubur semuanya dalam dokumen cukup lama untuk membuat kita keluar dari bisnis jika mereka benar-benar menginginkannya.
maple_shaft
Saya setuju dengan @sleske tentang penggunaan saluran hukum. Pastikan kontraknya baik, dan kemudian menuntut mereka jika mereka melanggar ketentuan. Atau setidaknya mengancam akan menuntut. Dalam apa yang saya lihat dari perusahaan besar, mereka sangat bersedia membayar vendor untuk menghindari tuntutan atau melanggar kontrak.
RationalGeek
@maple_shaft: Tidak tahu tentang situasi hukum di AS, tapi saya harap situasi hukum tidak seputus harapan Anda. Lagi pula, jika Anda diminta untuk menerapkan ini, saya hanya akan menunjukkan potensi masalah. Jika Anda masih mendapatkan lampu hijau (secara tertulis, tentu saja) Anda telah melakukan semua yang Anda bisa.
sleske
Tidak akan ada masalah memiliki sistem lisensi terbatas waktu di mana setelah lisensi berakhir aplikasi tidak berguna. Banyak perusahaan melakukannya, besar dan kecil - Adobe sebagai contoh.
James Snell
2

Jika mereka hosting secara internal, bagaimana ini berbeda dari perangkat lunak lain yang Anda kirimkan? Cari tahu apa yang akan Anda lakukan jika Anda mengirim, katakanlah, aplikasi tampilan inventaris desktop, dan lakukan itu.

David Thornley
sumber
Saya kira saya hanya bingung tentang apa yang harus dilakukan secara umum. Saya membayangkan bahwa aplikasi harus melakukan pemeriksaan setiap malam terhadap kunci lisensinya dengan mengirimkan permintaan ke server web eksternal dengan nomor lisensi. Respons akan berhasil atau gagal dan akan disimpan dalam variabel tingkat konteks aplikasi. Aplikasi pada dasarnya akan "mati" jika kunci lisensi tidak valid. Dengan cara ini kita dapat "membatalkan" nomor lisensi ini jika diperlukan.
maple_shaft
Apakah Anda berpikir bahwa halaman otentikasi lisensi sederhana ini harus dienkripsi SSL? Bahkan jika seseorang mengimplementasikan paket sniffer dan dapat memperoleh nomor lisensi yang valid, mereka akan perlu memiliki salinan aplikasi yang terdistribusi agar bermanfaat, dan bahkan kemudian itu dibuat dengan tujuan khusus. Saya tidak bisa membayangkan itu bermanfaat bagi siapa pun selain klien langsung saya.
maple_shaft
1

Tergantung sistemnya. Apakah Anda memperluas kerangka kerja yang ada seperti Magneto atau apakah Anda menulis seluruh aplikasi dari awal? Jika nanti, membangun persyaratan lisensi tidak terlalu sulit. Anda hanya mengirimkan aplikasi dengan lisensi jangka pendek, yang berakhir 45-hari setelah Anda menagih dan kemudian memberikan yang permanen nanti.

Ini mengasumsikan bahwa Anda juga tidak membalik sumbernya. :)

Christopher Bibbs
sumber
Kami tidak membalik sumbernya. Kami akan mengontrol kode sumber dan mendistribusikan rilis reguler dan perbaikan bug saat diperlukan.
maple_shaft
1
@maple_shaft: Yah, selalu ada kemungkinan hanya menolak untuk mengeluarkan perbaikan atau pembaruan sampai tagihan telah dibayar, karena saya curiga pemeliharaan dibangun untuk pembelian awal atau dijual sebagai hal yang berkelanjutan, dengan tanggal pembayaran reguler ( biasanya, tetapi tidak selalu, tahunan).
Vatine
Untuk menindaklanjuti @Vatine, Untuk proyek-proyek sebelumnya yang tidak memiliki perizinan yang kuat, kami telah menggunakan cacat sebagai titik pengungkit untuk mengekstraksi pembayaran. Beberapa cacat mungkin bukan kecelakaan total.
Christopher Bibbs
@maple_shaft - Jika Anda hanya memiliki satu klien. Solusinya sederhana. Jangan berikan pembaruan untuk program yang dimaksud kecuali saldo mereka adalah $ 0.
Ramhound
1

Mengingat bahwa sistem dihosting secara internal, banyak solusi yang disebutkan di atas yang melibatkan komunikasi dengan server jauh mungkin tidak berfungsi.

Mengapa tidak memasukkan file lisensi di dalam proyek yang menyertakan tanggal kedaluwarsa. Setelah jam sistem melebihi tanggal kedaluwarsa, sistem berhenti berfungsi. Untuk mengamankan file, enkripsi konten untuk mencegah gangguan. Ketika pengguna membayar, atau memperbarui selama satu tahun tambahan, Anda mengirimi mereka file lisensi baru.

Perhatikan bahwa jika Anda menggunakan PHP, kode tersebut sudah tersedia bagi pengguna untuk diedit, jadi apa pun keamanan yang Anda lakukan, pengguna dapat dengan mudah masuk dan menghapusnya. Jika Anda menggunakan ASP.NET atau bahasa kompilasi lainnya, ini bukan masalah karena kode tidak dapat dimodifikasi.

Gavin Coates
sumber
Ini adalah saran yang bagus tetapi ini adalah aplikasi Java yang dipaket dan digunakan. Memberi mereka file lisensi baru berarti memercayai mereka untuk memasukkannya dengan benar ke file WAR atau memberi mereka file WAR yang sama sekali baru yang akan mengganggu bagi semua orang. Mereka memiliki tumpukan dokumen dan banyak orang IT yang perlu membenarkan keberadaan mereka di dalam organisasi mereka dengan terlibat setiap kali ada rilis baru dari aplikasi pihak ketiga. Saya tidak mengecilkan saran Anda hanya itu mungkin saran yang paling tidak ofensif.
maple_shaft
Saya kira bahkan dengan sebagian besar bahasa yang dikompilasi seperti java, toples dapat dengan mudah dikompilasi, diperbarui, dikompilasi ulang, dan kemudian dimasukkan ke dalam perang, jadi bagaimana seseorang mengatasinya?
Sudarshan
1

(Pengungkapan - Saya bekerja untuk Agilis Software, penyedia sistem manajer lisensi ).

Solusi paling efektif adalah menggunakan aktivasi produk otomatis dengan sewa lisensi. Di luar kotak, ini memungkinkan Anda untuk:

  • Secara otomatis mengaktifkan lisensi pelanggan. Pada waktu aktivasi, setiap instance dikunci secara otomatis ke parameter yang Anda pilih dari sistem target, dan batas lisensi yang Anda atur untuknya akan diberlakukan pada aplikasi Anda (mis. Mengkonfigurasi fitur, mengatur uji coba keseluruhan atau batas waktu berlangganan).
  • Tetapkan 'interval sewa', yang merupakan periode validitas maksimum dari satu peristiwa aktivasi. Untuk pelanggan dengan kredit yang dicurigai Anda dapat mengatur ini, katakan dua minggu, yang berarti setiap dua minggu aplikasi Anda akan secara otomatis 'telepon rumah' di latar belakang untuk memvalidasi ulang lisensi. Jika mereka terlambat membayar Anda dapat menonaktifkan lisensi mereka di server yang dihosting dan itu akan berhenti berjalan di rumah telepon berikutnya.
  • Jika tidak ada koneksi jaringan dari sistem target, ada proses aktivasi swalayan pengguna melalui pertukaran file terenkripsi di terminal web mana pun. Jika pengguna Anda berada dalam posisi ini maka Anda mungkin ingin membuat interval sewa lebih lama untuk menyeimbangkan ketidaknyamanan kepada mereka dengan kebutuhan Anda untuk dibayar. Setelah mereka membayar, Anda dapat membuat interval sewa selama Anda suka, hingga abadi.
Dominic
sumber