Phỏng vấn về Hash thành công - Giúp Lập Trình Viên được trả lương cao
ฝัง
- เผยแพร่เมื่อ 1 มิ.ย. 2024
- Giải thích về hash. Vì sao phải là hash?
👉 Link khóa học backend Nodejs: / @anonystick
Timeline:
00:00 4 vấn đề về cơ chế bảo mật password?
03:27 Vì sao 6 tháng đổi mật khẩu một lần?
04:20 Vì sao mật khẩu mới bắt buộc không giống mật khẩu cũ?
07:10 Cách so sánh password hash dựa vào đâu?
10:29 Thuật toán Hash có thể hai chiều được không?
🚩 Subscribe ➜ / tipsjavascript
#hashing #anonystick #developer
✅ Follow Me:
Blog: anonystick.com
Github: github.com/anonystick/anonystick
Facebook: / tipjs
TH-cam: / tipsjavascript
anh có video nào về live stream video chưa ạ
như fb bây giờ nó lưu quá nhiều mật khẩu cũ bác ạ, chứ không phải chỉ 1-2 pass gần nhất
Hello mn
Chỉ biết thả ❤ 😃
❤❤
cho e hỏi mình lưu hashPass thôi, còn phần salt thì lấy 30bit đầu tiên của hashPass đúng k ạ của
Không em, salt có method để lấy ra random 128 bit gì đó...
@@anonystick dạ e cảm ơn. Tại lúc e có vọc vạch hàm compare của bcryptjs, thì e thấy nó lấy password mình nhập vào: hashSync(password, hash.substring(0, 29)), nên e cứ tưởng mặc định nó chỉ lấy 30bit đầu là salt.
7:49 cái file đó là bcrypt nó tự tạo xong lưu chữ đúng không ạ
Mình chứ...
❤
Em có một web tool dịch vụ làm cho vui mà giờ lỡ có user dùng nhiều. Các đối thủ khác cũng tấn công nhiều cách khác nhau. Thì phải làm sao để bảo mật ạ. BE là express ạ
CHo ví dụ đi em...
@@anonystick dạ. Web tool đăng bài fb/tiktok/youtube ạ. Vps dùng linux. Server dùng express. Có các đối thủ vào DDOS và quét port database để phá. E muốn bảo mật tốt web dịch vụ thầy ạ
e có cái mk tài khoản bank. giờ quên mất tiu cũng vì bank bắt đổi mk. cay cú
chào anh em muốn hỏi 1 câu hỏi, e có 2 bảng sinh viên và đoàn trường có tài khoản , 1 là tạo theo hướng tài khoản của ai đó, 2 là sinh viên có tài khoản nên đi theo hướng nào và tạo tài khoản trước hay tạo đối tượng (sinh viên, đoàn trường) trước, em cảm ơn ạ
Em có thể nói rõ hơn được không hen? Anh chưa hiểu lắm?
@@anonystick dạ cụ thể nên xây dựng ở trong bảng sinh viên có mã tài khoản hay bảng tài khoản có mã sinh viên ạ
@@anonystick dạ em có 3 đối tượng như sau:
- sinh viên :có quyền đăng ký hoạt động và đăng ký tổ chức hoạt động nếu là cán bộ và được duyệt các sinh viên đăng ký các hoạt động của sinh viên đó tạo ra
- đoàn trường :có quyền đăng ký tổ chức hoạt động và duyệt các hoạt động các cán bộ đăng ký và duyệt tham gia các hoạt động đó
-admin :là người có toàn quyền tạo hoạt động không cần kiểm duyệt và duyệt các hoạt động của đoàn trường tạo
vậy nên tạo mấy bảng tài khoản cho đúng chuẩn khi xây dựng bảng chi tiết hoạt động
dạ em cảm ơn ạ
Nói về quyền thì ở đây có 3 roles. Em xem lại video về phân quyền trong Member mình thêm. Thứ hai đó là em nên đi từ tạo sinh viên, sau đó tạo event, tiếp đến duyệt event thì mới public ra cho sinh viên đăng ký. Sinh viên không có quyền truy cập vào chỉnh sửa event. Cứ như thế cho đơn giản em hen
Nếu tập trung vào phần quyền như bạn thì sẽ chú trọng vào 2 bảng
Trong đó TABLE SINHVIEN chưa thông tin sinh viên và tài khoản đăng nhập
bản PHANQUYEN chứa tên quyền truy cập ứng với cái roles như (SV, ĐT, AD) do mình tự định nghĩa, username của Sinh viên (rel SINH VIEN) và level truy cập (1,2,3,4) phòng sau này truy cập còn kèm theo level nữa
Đại khái khi access vào các tính năng phân quyền nó sẽ check trước người đó có phân quyền đó không và level access có đủ để truy cập không. Cách này là dễ nhất
vì cái bank cứ bắt đổi pass liên tục không thể nhớ nên phải xài thêm Keepass :D
Phiền quá em hè
Chào anh, em muốn hỏi một câu hỏi. Trong các hệ thống ngân hàng, ví dụ em là nhân viên dev của ngân hàng, được quyền truy cập vào database product, thì em sửa số dư trong tài khoản của mình thành 1 tỷ😅. Vậy làm sao để các ngân hàng check được điều này và ngăn chặn
theo mik nghĩ thì Dev không bao giờ được chạm vô data thật đâu, data mà cho Dev trong khi code phải qua xử lý xào nấu rồi, không làm vậy thì nhà nước phạt ngay vì luật đã quy định. Với lại ngân hàng họ hoạt động thì chắc chắn phải có bộ phận kiểm toán hay bộ phận có chức năng tương tự như vậy và quy trình chắc chắn phải rất phức tạp 😢
Mình đang làm bank đây b. Đầu tiên dev thì chỉ được vào môi trường test thôi. Còn môi trường production thì phải chuyên gia mới được làm, và khi đụng đến môi trường production sẽ phải giám sát. Chưa kể mọi hành động bạn làm trên server sẽ được ghi lại vào log từng keyword bạn gõ. Nên kể cả khi bạn làm gì thì người ta vẫn trace được dựa vào log nhé. Đội bảo mật ngân hàng sẽ lo vụ đó😊
@@JavaOnly_ cảm ơn bạn
Trong ngân hàng hay bất kì doanh nghiệp đầu tư nghiêm túc thì
1. Luôn có 2 môi trường Prod và Test riêng nên nếu chỉ là dev quèn thì chỉ access được level Test thôi không thế access được vào Prod nếu không có thẩm quyền.
2. Vậy ông Dev có thẩm quyền access thì ổng có sửa được không thì câu trả lời là không vì source code và database thông thường là không làm trực tiếp mà phải thông qua một mớ xác thực thì mới có quyền đọc hoặc ghi một dữ liệu nào đó, nên ông nào có suy nghĩ mình sẽ inject một code nào vào mà lớ ngớ là ăn ngay log của hệ thống giám sát. Đọc còn khó chứ đừng nói là tới sửa một số liệu nhỏ.
3. Ở level cao hơn là mấy ông về hệ thống, bảo mật. Mấy ông này lương cao. Và cũng không dại dột gì là trò đó nếu không muốn tàn đời. Vì các data ngân hàng luôn được giám sát và audit tự động nên cho là mấy ông có quyền R/W vào DB thì chỉ cần tạo một cái gì đó bất thường thì kiểu chi cũng lòi ra vì họ luôn được giám sát chéo nhau. Nó cũng tương tự như block chain nếu không ai chuyển tiền cho mình thì không có lí do gì mà tiền mình lại tăng hoặc ngược lại nếu mình không chuyển tiền đi thì không có lí do gì mà tiền mình lại giảm. Nếu bạn có ý tạo một giao dịch giả thì tất cả giao dịch luôn có một mã riêng và không trùng hợp với bất kì giao dịch nào trong cùng một ngân hàng. Phải có giao dịch A thì mới có giao dịch sau A nên việc tự nhiên có một giao dịch hay một số tiền tào lao trong hệ thống là điều không thể, và nó sẽ phát hiện qua việc Audit dữ liệu thực tế và các công cụ giám sát liên tục.
Khi trang web check được mật khẩu có ngày sinh của user thì chứng tỏ trang web đó không hash mà lưu dưới dạng raw luôn đúng không mọi người nhỉ?
cái đó trên font-end check vẫn được mà không cần đẩy lên backend để check.
nếu mà trên font-end sẽ có khái niệm form validation. Nó sẽ kiểm tra hết dữ liệu trước khi gửi lên backend
và font-end làm được thì back-end làm cũng được
Để chống SQL Injection thì các dữ liệu gửi từ user lên luôn được check trước khi đưa vào truy vấn thì bước này cũng na ná như form validation trên FE, thì bước này đồng thời kiểm tra tính hợp lệ dữ liệu luôn vẫn được. Nên okela hết thì lưu lại còn không thì trả mã lỗi về user thôi :D. Sau khi FE/BE ok hết thì mới tới công đoạn sinh hash hoặc mật khẩu đã mã hóa :D. Rồi mới lưu vào DB.
dạo này em không thấy anh ra video về GoLang vậy ạ
Trong member chuẩn bị dự án về Go nha em.
Em muốn hk khoá node js kênh mình thì phải đăng ký ntn vậy mn?
Do ko hiểu sao kênh mình e ko thấy nút đăng ký hội vien nữa!
Em dùng web or android á. iOS không hiện.
@@anonystick ios a aj
3 tháng đổi một lần, mk mới k giống cũ. Máy dùng xác thực thêm faceid. Vậy nhớ sao dk password... 3 tháng k nhập lần nào thì nhớ sao ta...
Chắc bấm quên pass ấy b
@@nqmgaming2004 k còn cách nào khác. :d hix
Là sao chưa hiểu mr Hoàng!
@@anonystick ý e hơi bất cập cho người dùng với faceid ấy a
@@anonystick ko thể nhớ đc mk ấy anh. em toàn đặt bừa. sau app yêu cầu mật khẩu thì chọn quên mật khẩu rồi lại đặt bừa chủ yếu để sử dụng được app xong lưu lại app vài mấy trình quản lý pass. nói chung ý tưởng thì dev là tốt nhưng lại gây ra phiền phức cho người dùng. mỗi người có vài chục cái mật khẩu, như em làm qlvh ngoài mật khẩu cá nhân còn mật khẩu hệ thống của mấy chục cái app quản lý khác nữa, mỗi lần app yêu cầu đổi gần như toàn là chọn quên mật khẩu để cấp lại. lúc trước còn lưu lại file. sau bận quá không còn thời gian để sửa danh sách nữa nên chịu trận và chọn cách quên mật khẩu.
lan man không vào trọng tâm
❤