OneTimeSecret در برابر PrivateNote: چرا محل رمزگذاری مهم است
OneTimeSecret روی سرورهای خود رمزگذاری می‌کند. PrivateNote پیش از ترک راز از دستگاه شما رمزگذاری می‌کند.
هر دو پیوندی موقت می‌فرستند. OneTimeSecret روی سرورهای خود رمزگذاری می‌کند، بنابراین راز شما آنجا به‌صورت متن خوانا می‌رسد. اگر عبارت عبور اضافه کنید، آن هم به سرویس می‌رود. PrivateNote نخست روی دستگاه شما رمزگذاری می‌کند. سرویس فقط پیام رمزشده را دریافت می‌کند. عبارت عبور اختیاری روی دستگاه شما می‌ماند و اگر کس دیگری پیوند را به دست آورد، از کلید محافظت می‌کند.
Key takeaways
- هر دو پیوندهای موقت را رمزگذاری می‌کنند. تفاوت در محل رمزگذاری است.
- OneTimeSecret روی سرور رمزگذاری می‌کند، بنابراین راز و عبارت عبور هنگام ساخت و دوباره هنگام بازیابی به سرویس می‌رسند.
- PrivateNote نخست روی دستگاه رمزگذاری می‌کند. کلید سمت کلاینت می‌ماند؛ اگر پیوند افشا شود، عبارت عبور آن را به‌صورت محلی می‌پوشاند.
- این مرز اعتماد را تغییر می‌دهد: سرور PrivateNote به متن ساده نیاز ندارد. پایگاه داده سرقت‌شده همچنان کلیدها را ندارد؛ مرورگر نفوذشده هنگام استفاده ریسک متفاوتی است.
OneTimeSecret و PrivateNote یک مسئله عملی را حل می‌کنند: جابه‌جایی گذرواژه، کلید API، کد بازیابی، یا یادداشت محرمانه از طریق پیوندی موقت، به‌جای باقی گذاشتن متن ساده در ایمیل یا گفتگو. گیرنده پیوند را باز می‌کند، و محموله ذخیره‌شده می‌تواند پس از خوانده شدن یا با رسیدن زمان انقضا ناپدید شود.
هر دو محصول محموله را رمزگذاری می‌کنند. تفاوت مهم این است که رمزگذاری کجا رخ می‌دهد.
OneTimeSecret پس از رسیدن راز شما به سرورهایش رمزگذاری می‌کند، بنابراین سرویس نخست متن خوانا را می‌بیند. PrivateNote نخست روی دستگاه شما رمزگذاری می‌کند، بنابراین سرویس فقط پیام رمزشده را دریافت می‌کند.
دو راه برای ساختن همان پیوند
در رمزگذاری سمت سرور، فرستنده راز را روی TLS به سرویس می‌فرستد. سرویس متن ساده را دریافت می‌کند، آن را رمزگذاری می‌کند، و متن رمزشده را ذخیره می‌کند. سپس می‌تواند محموله را ذخیره کند، تحویل دهد، منقضی کند، و حذف کند. سرور برنامه بخشی از فرایند رمزگذاری است، چون متن ساده پیش از تبدیل شدن به متن رمزشده وارد سرویس می‌شود.
در رمزگذاری سمت کلاینت، دستگاه فرستنده نخست رمزگذاری می‌کند. سرویس متن رمزشده را دریافت و ذخیره می‌کند. آن بارگذاری روی TLS سفر می‌کند. سرویس کلید لازم برای رمزگشایی محموله استاندارد را دریافت نمی‌کند. دستگاه گیرنده به‌صورت محلی رمزگشایی می‌کند. سرویس همچنان می‌تواند محموله را ذخیره کند، تحویل دهد، منقضی کند، و حذف کند، بدون آنکه به متن ساده آن نیاز داشته باشد.
هر دو طراحی می‌توانند پیوند موقت، دسترسی محدود، و انقضا فراهم کنند. هر دو را می‌توان به‌درستی رمزگذاری‌شده توصیف کرد. OneTimeSecret معماری نخست را به کار می‌برد؛ PrivateNote معماری دوم را. بنابراین پرسش مربوط صرفاً این نیست که آیا پیوند یک‌بارمصرف رمزگذاری شده است، بلکه این است که برای کار کردن آن پیوند، کدام سامانه‌ها باید به متن ساده دسترسی داشته باشند.
OneTimeSecret: رمزگذاری سمت سرور
در مسیر معمولی OneTimeSecret، فرستنده راز را روی TLS می‌فرستد. برنامه متن ساده را دریافت می‌کند، آن را روی سرور رمزگذاری می‌کند، و محموله رمزشده را ذخیره می‌کند.
این محافظت معناداری برای داده ذخیره‌شده فراهم می‌کند. به‌دست آوردن تنها ذخیره رمزشده، وقتی ماده لازم برای رمزگشایی در دسترس مهاجم نباشد، لزوماً محتوای آن را آشکار نمی‌کند.
بده‌بستان معماری پیش از ذخیره‌سازی رخ می‌دهد. TLS راز را هنگام سفر میان مرورگر و OneTimeSecret محافظت می‌کند، اما برنامه باید متن ساده را پردازش کند تا آن را رمزگذاری کند. بنابراین سرور برنامه داخل مرز اعتماد رمزنگاری می‌نشیند.
فرایند برنامه مخرب یا نفوذشده در آن لحظه می‌تواند پیش از رمزگذاری برای ذخیره‌سازی به راز دسترسی داشته باشد. رمزگذاری سمت کلاینت این وابستگی خاص را برمی‌دارد، با رمزگذاری راز پیش از رسیدن آن به سرویس.
عبارت عبور OneTimeSecret مرز رمزگذاری را تغییر نمی‌دهد
مستندات OneTimeSecret عبارت عبور اختیاری را توصیف می‌کند. وقتی عبارت عبور به کار رود، OneTimeSecret می‌گوید راز روی سرورهایش با عبارت عبوری که فرستنده داده رمزگذاری می‌شود. می‌گوید خود عبارت عبور را ذخیره نمی‌کند؛ در عوض، درهم‌ساز bcrypt را نگه می‌دارد که هنگام بازیابی برای تأیید عبارت عبور به کار می‌رود. طبق مستنداتش، آن درهم‌ساز به‌خودی‌خود نمی‌تواند راز را رمزگشایی کند، و راز ذخیره‌شده محافظت‌شده با عبارت عبور را نمی‌توان بدون عبارت عبور اصلی رمزگشایی کرد.
بازیابی از همان مرز سمت سرور استفاده می‌کند. گیرنده عبارت عبور را روی TLS به OneTimeSecret می‌دهد. سرویس آن را تأیید می‌کند و رمزگشایی را روی سرور انجام می‌دهد، پیش از بازگرداندن متن ساده.
این یعنی فرایند برنامه هنگام رمزگذاری به راز و عبارت عبور دسترسی دارد، و هنگام بازیابی دوباره عبارت عبور و متن ساده حاصل را پردازش می‌کند. فرایند برنامه مخرب یا نفوذشده که در هر یک از این دو نقطه کار کند، بالقوه می‌تواند آن اطلاعات را ضبط کند. این پیامد محل اجرای رمزگذاری و رمزگشایی است، نه ادعایی که OneTimeSecret آن مقادیر را ثبت یا سوءاستفاده می‌کند.
مستندات عمومی OneTimeSecret به‌خودی‌خود همه جزئیات سلسله‌مراتب کلید داخلی را ثابت نمی‌کند—برای مثال، دقیقاً چگونه ماده کلید سمت سرور، کلیدهای هر راز، مشتق کلید، و عبارت عبور داده‌شده با هم ترکیب می‌شوند. برای این مقایسه نیازی به گمانه‌زنی درباره آن جزئیات پیاده‌سازی نیست. ویژگی مستندشده مربوط این است که رمزگذاری و رمزگشایی در سمت سرویس رخ می‌دهد.
OneTimeSecret
راز + عبارت عبور
سرور
متن رمزشده
خودمیزبانی می‌تواند آن اعتماد به سرور را معقول کند
OneTimeSecret متن‌باز است. سازمان می‌تواند نمونه خود را داخل محیط امنیت سازمانی اجرا کند، به‌جای فرستادن راز به سرویس عمومی.
در آن استقرار، اعتماد به سرور برنامه یعنی اعتماد به زیرساختی که سازمان از قبل اداره می‌کند. متن ساده همچنان به آن سرور می‌رسد، چون رمزگذاری همچنان همان‌جا رخ می‌دهد. طرف دیگر مرز، میزبان‌ها، گردانندگان، و پشتیبان‌های خود سازمان است. برای تیمی که از قبل آن سامانه‌ها را بخشی از مسیری می‌داند که راز طی می‌کند، رمزگذاری سمت سرور می‌تواند انتخاب معقولی باشد. شکاف میان مدل تهدید سمت سرور و سمت کلاینت را باریک می‌کند، چون گرداننده دیگر سرویس بیرونی نیست.
PrivateNote پیش از بارگذاری رمزگذاری می‌کند
یادداشت استاندارد PrivateNote پیش از بارگذاری رمزگذاری می‌شود. مرورگر فرستنده، یا فرایند محلی CLI، افزونه Chrome، افزونه ویرایشگر، یا MCP، کلید تصادفی می‌سازد و محموله را با AES-256-GCM رمزگذاری می‌کند. فقط متن رمزشده بارگذاری می‌شود. TLS آن متن رمزشده را از مرورگر به Cloudflare worker در PrivateNote می‌برد. کلید رمزگشایی در قطعه URL قرار می‌گیرد، بخش پس از #، برای مثال https://privatenote.ai/note/abc123#…. قطعه سمت کلاینت مدیریت می‌شود و در درخواست HTTPS گنجانده نمی‌شود (RFC 3986، بند 3.5؛ استاندارد URL). worker شناسه یادداشت را دریافت می‌کند و متن رمزشده را روی همان اتصال TLS برمی‌گرداند. مرورگر قطعه را نگه می‌دارد و به‌صورت محلی رمزگشایی می‌کند.
عبارت عبور در صورت نفوذ به کانال ارسال پیوند، از کلید محافظت می‌کند
عبارت عبور در PrivateNote کاری متفاوت از عبارت عبور در OneTimeSecret می‌کند. یادداشت پیش از ترک دستگاه از قبل متن رمزشده است. اگر عبارت عبور اضافه کنید، مرورگر با Argon2id کلید پوششی از آن مشتق می‌کند و از آن کلید پوششی برای رمزگذاری کلید یادداشت استفاده می‌کند. قطعه URL سپس کلید پوشیده‌شده را نگه می‌دارد. گیرنده به پیوند و عبارت عبور نیاز دارد. مرورگر کلید را به‌صورت محلی می‌گشاید و فقط سپس یادداشت را رمزگشایی می‌کند.
PrivateNote عبارت عبور را دریافت نمی‌کند. درخواست ساخت، متن رمزشده، نمک، و پارامترهایی را حمل می‌کند که مرورگر گیرنده برای آزمودن عبارت عبور به‌صورت محلی نیاز دارد. درهم‌ساز سمت سروری وجود ندارد که کارش تأیید عبارت عبور باشد. عبارت عبور نادرست، رمزگشایی را روی دستگاه ناموفق می‌کند.
عبارت عبور علاوه بر این، کلید سمت کلاینت را به‌صورت محلی محافظت می‌کند اگر کانال حامل پیوند نفوذ شود. آن کانال سپس کلید پوشیده‌شده می‌بیند، نه کلیدی که به‌خودی‌خود بتواند یادداشت را باز کند. این سازوکاری نیست که PrivateNote را بیرون از مسیر متن ساده نگه می‌دارد. آن جدایی از قبل روی یادداشت استاندارد هست، با عبارت عبور یا بدون آن. عبارت عبور را در کانالی متفاوت از پیوند به اشتراک بگذارید. همان پیام دو لایه را به یک لایه فرو می‌ریزد — همان قاعده اشتراک امن گذرواژه.
PrivateNote
راز
رمزگذاری محلی
متن رمزشده
سرور
عبارت عبور
Argon2id محلی
کلید پوشیده‌شده
قطعه URL
همان جدایی، هر بار یک ویژگی.
| OneTimeSecret + عبارت عبور | PrivateNote + عبارت عبور | |
|---|---|---|
| رمزگذاری محموله | سرور | دستگاه فرستنده |
| متن ساده به سرویس می‌رسد | بله | خیر |
| عبارت عبور به سرویس می‌رسد | بله | خیر |
| نقش عبارت عبور | در محافظت سمت سرور شرکت می‌کند | کلید پوششی محلی مشتق می‌کند |
| تأییدکننده یا ماده ذخیره‌شده | تأییدکننده bcrypt و محموله رمزشده، طبق مستندات OneTimeSecret | نمک، پارامترهای پوشش Argon2id، و متن رمزشده |
| رمزگشایی کجا اجرا می‌شود | سرور برنامه OneTimeSecret | دستگاه گیرنده |
مدیریت کلید PrivateNote در نحوه کار توصیف شده است: کلید محتوا با Argon2id پوشیده می‌شود، و کلید پوشیده‌شده در پیوند سفر می‌کند.
فرض اعتماد باقی‌مانده به کلاینت وب
رمزگذاری سمت کلاینت در مرورگر، برنامه وب بی‌نیاز از اعتماد نیست. رمزنگاری می‌تواند به‌صورت محلی اجرا شود در حالی که JavaScript پیاده‌کننده آن را سایت تحویل می‌دهد. مرورگر به کدی که برای آن نشست دریافت می‌کند اعتماد می‌کند.
کسی که بتواند آن JavaScript را تغییر دهد — از طریق برنامه، CDN، یا خط لوله استقرار — می‌تواند کلاینت را عوض کند و کلیدها را در نشست آینده مرورگر ضبط کند. این شکستی متفاوت از دزدیدن پایگاه داده است. نفوذ به ذخیره، متن رمزشده را افشا می‌کند. تحویل کد مخرب به نقطه پایانی حمله می‌کند در حالی که کلید واقعاً حاضر است.
رونوشت بعدی پایگاه داده نمی‌تواند کلیدهای سمت کلاینتی بسازد که هرگز آنجا ذخیره نشده‌اند. کلاینت فعالِ نفوذشده می‌تواند به رازهایی که در آن نشست مدیریت می‌شوند حمله کند. همین فرض در مدل تهدید PrivateNote نوشته شده است: کد برنامه تحویل‌شده به‌صورت مخرب تغییر نکرده، و دستگاه فرستنده و گیرنده در لحظه رمزگذاری و رمزگشایی مورد اعتمادند.
نرم‌افزار نصب‌شده آن وابستگی به صفحه تازه‌بارگیری‌شده را باریک می‌کند. CLI، افزونه ویرایشگر، یا برنامه بومی کدی را اجرا می‌کند که شما نصب کرده‌اید. آن کلاینت‌ها همچنان به سیستم‌عامل، امضا، وابستگی‌ها، و کانال به‌روزرسانی وابسته‌اند. ابزارهای توسعه‌دهنده همان جدایی مرورگر را به کار می‌برند: رمزگذاری محلی، بارگذاری متن رمزشده، و باقی گذاشتن کلید در قطعه.
طول عمر و محرمانگی
پیوند یک‌بارمصرف به دو پرسش جدا پاسخ می‌دهد. محموله رمزشده تا چه مدت باید وجود داشته باشد؟ و تا وقتی وجود دارد چه کسی می‌تواند آن را رمزگشایی کند؟ نابود کردن آن پس از بازیابی یا انقضا، پنجره را کوتاه می‌کند. تعیین نمی‌کند در آن پنجره چه کسی می‌توانست آن را بخواند. طول عمر و محرمانگی یکدیگر را پشتیبانی می‌کنند. یکی جای دیگری را نمی‌گیرد.
تمایز وقتی محموله اختیار است تیزتر می‌شود: کلید API، اطلاعات ورود پایگاه داده، توکن ابری، کد بازیابی، گذرواژه زیرساخت. سرویس اشتراک راز وجود دارد چون فرستنده می‌خواهد آن اطلاعات به سامانه‌های کمتری سپرده شود. اگر واسط فقط باید شیء رمزشده مات را حمل کند، انقضا را اعمال کند، و آن را حذف کند، سرور می‌تواند آن کار را بدون دریافت راز یا کلیدی که آن را باز می‌کند انجام دهد.
مرز اعتماد کجاست
«رمزگذاری‌شده» به شما نمی‌گوید مرز اعتماد کجا می‌نشیند. استانداردی که ارزش استفاده دارد مرز اعتماد حداقلی است: اصل کمترین امتیاز، اعمال‌شده بر اینکه چه کسی باید متن ساده را ببیند. در مهندسی رمزنگاری امروز، هدف صرفاً اعتماد به رفتار سرور نیست، بلکه کم کردن ضرورت ریاضی اعتماد از همان ابتدا است.
OneTimeSecret سامانه‌ای با رمزگذاری سمت سرور را توصیف می‌کند. با محافظت عبارت عبور، می‌گوید راز ذخیره‌شده را نمی‌توان بعداً بدون عبارت عبور رمزگشایی کرد، و نفوذ به سرور راز را امن باقی می‌گذارد تا وقتی آن عبارت عبور ناشناخته بماند. عبارت عبور ضعیف را می‌توان با جستجوی فراگیر شکست. اگر ضعیف باشد، آن نفوذ همچنان می‌تواند راز را قابل‌بازیابی بگذارد. متن ساده و عبارت عبور هنگام ساخت به OneTimeSecret می‌رسند، چون رمزگذاری روی سرورهایش رخ می‌دهد، و عبارت عبور هنگام بازیابی بازگردانده می‌شود تا آن سرورها بتوانند رمزگشایی کنند.
PrivateNote انتخاب معماری متفاوتی می‌کند. محموله پیش از رسیدن به سرویس رمزگذاری می‌شود، و کلید محموله استاندارد سمت کلاینت می‌ماند. عبارت عبور، وقتی یکی تنظیم می‌کنید، علاوه بر این آن کلید سمت کلاینت را به‌صورت محلی محافظت می‌کند اگر کانال حامل پیوند نفوذ شود. به PrivateNote فرستاده نمی‌شود.
OneTimeSecret راز شما را رمزگذاری می‌کند. کلاینتی که از سرویس PrivateNote استفاده می‌کند آن را پیش از دریافت سرویس رمزگذاری می‌کند. این تمایز به فرض مخرب بودن هیچ‌یک از ارائه‌دهندگان وابسته نیست. پرسش را به معماری فرو می‌کاهد: چند سامانه برای کار کردن سرویس به دسترسی به متن ساده نیاز دارند؟
پرسش‌های رایج
آیا OneTimeSecret راز را به‌صورت متن ساده ذخیره می‌کند؟
مستنداتشان می‌گوید خیر. آن‌ها روی سرورهای خود رمزگذاری می‌کنند. با عبارت عبور، می‌گویند راز رمزشده و درهم‌ساز bcrypt عبارت عبور را ذخیره می‌کنند، نه خود عبارت عبور را، و آن درهم‌ساز نمی‌تواند راز را رمزگشایی کند.
اگر در OneTimeSecret عبارت عبور تنظیم کنم، آیا راز از سرورهایشان پنهان است؟
نه هنگام ساخت، و نه هنگام بازیابی. OneTimeSecret می‌گوید راز و عبارت عبور به سرورش داده می‌شوند تا سرور بتواند رمزگذاری را انجام دهد. وقتی گیرنده پیوند را باز می‌کند، عبارت عبور را روی TLS برمی‌گرداند، و رمزگشایی روی سرورهای OneTimeSecret اجرا می‌شود پیش از بازگرداندن متن ساده. پس از رمزگذاری، OneTimeSecret می‌گوید عبارت عبور متن ساده را کنار می‌گذارد، فقط درهم‌ساز bcrypt را نگه می‌دارد، و نمی‌تواند راز ذخیره‌شده را بدون عبارت عبور اصلی رمزگشایی کند.
عبارت عبور PrivateNote از چه چیزی محافظت می‌کند؟
از کلید سمت کلاینت، اگر کانال حامل پیوند نفوذ شود. خود یادداشت از قبل روی دستگاه شما با AES-256-GCM رمزگذاری شده است. Argon2id کلید پوششی را از عبارت عبور به‌صورت محلی مشتق می‌کند، و آن کلید پوششی کلید یادداشت را رمزگذاری می‌کند. پیوند سپس کلید پوشیده‌شده را نگه می‌دارد. PrivateNote متن رمزشده و نمک دریافت می‌کند. عبارت عبور یا کلید خام را دریافت نمی‌کند. یادداشت استاندارد حتی بدون عبارت عبور پیش از بارگذاری رمزگذاری می‌شود. عبارت عبور را در کانالی جدا از پیوند بفرستید.
آیا رمزگذاری سمت کلاینت در برابر سرور نفوذشده PrivateNote محافظت می‌کند؟
نفوذ به داده ذخیره‌شده یا API: بله، به این معنا که رمزگذاری سمت کلاینت محموله‌های خوانده‌نشده را جدا می‌کند، چون سرور کلید محموله استاندارد را ندارد. رونوشت بعدی پایگاه داده نمی‌تواند کلیدهایی بسازد که هرگز آنجا ذخیره نشده‌اند. تحویل کد کلاینت مخرب: خیر. مهاجمی که بتواند JavaScript تحویل‌شده به نشست آینده مرورگر را تغییر دهد، می‌تواند تلاش کند کلید را وقتی حاضر است ضبط کند. کلاینت‌های نصب‌شده آن وابستگی به صفحه تازه‌بارگیری‌شده را کم می‌کنند.
منابع اصلی
اطلاعات معماری درباره OneTimeSecret در برابر مستندات عمومی آن در 23 سپتامبر 2026 بررسی شد. پیاده‌سازی محصول و مستندات ممکن است تغییر کنند.
- مستندات OneTimeSecret
- OneTimeSecret درباره امنیت و عبارت عبور
- کد منبع OneTimeSecret
- رمزگذاری PrivateNote چگونه کار می‌کند
- PrivateNote برای توسعه‌دهندگان، از جمله CLI
- RFC 3986، بخش 3.5، که قطعه را پیش از ارجاع از URI جدا می‌کند
- استاندارد URL، قطعه، درباره مدیریت سمت کلاینت قطعه
پیش از ترک راز از دستگاه رمزگذاری کنید
یادداشت را در مرورگر بنویسید. کلاینت آن را به‌صورت محلی رمزگذاری می‌کند، کلید را در پیوند می‌گذارد، و می‌تواند آن کلید را با عبارت عبوری محافظت کند که سرور هرگز دریافت نمی‌کند.
