Mình tìm kiếm mãi mà không thể down về được bản Meta Stock 10. Có huynh nào biết xin chỉ địa chỉ download giùm và nếu có cả crack thì càng tốt. Xin cảm ơn các huynh. 

Tại sao phải hash? Giả sử user A có password là a, password này được application "hash" nó thành 0cc175b9c0f1b6a831c399e269772661 rồi chứa vào CSDL. Khi user A login và dùng password a để đăng nhập, application sẽ hash a và so sánh giá trị vừa hash xong với giá trị đã lưu trong CSDL. Nếu chúng trùng nhau, user A được vào. Nếu hệ thống bị nhân nhượng, kẻ tấn công chỉ thu thập được hashed password và nếu muốn dùng chúng, hắn phải brute force nó (mất thời gian và ít thành công). 

Xin "đào mồ" chủ đề này xíu, em đọc thảo luận của các bác cũng sáng ra nhiều vấn đề. Theo em hiểu thì phương pháp hash một dữ liệu (password) thì sẽ giảm khả năng lộ password dạng đọc được trên đường truyền, và người không thẩm quyền cũng chỉ có được một chuỗi kỹ tự loằng ngoằng mà họ không đọc được. Tuy nhiên, cái em thắc mắc là khi đó họ sử dụng trực tiếp luôn cái chuỗi đó chữ không cần dịch lại làm gì cả, vì chuỗi đó là duy nhất mà (tính chất của hàm hash).
Vậy thì hash password, theo em nó chỉ che mắt được chứ không có tác dụng bảo vệ, không biết em nghĩ có sai không. Cảm ơn các bác. 

Mình nghĩ những giải pháp như RSA SecurID chỉ phù hợp với môi trường xác thực khách hàng bên ngoài sử dụng các dịch vụ công mà doanh nghiệp cung cấp như thương mại điện tử hay ngân hàng điện tử.

Dùng RSA SecurID cho các loại hình dịch vụ này thiệt ra cũng chỉ là tô vẽ thêm cho khách hàng an tâm và hơn hết là làm đúng quy định của nhà chức trách thôi, chứ nếu tính toán về chi phí và hiệu quả thì mình không nghĩ dùng RSA SecurID là giải pháp tối ưu cho bài toán xác thực hai yếu tố.



-m 

Mình cũng cho rằng, đem RSA SecurID vào áp dụng cho môi trường doanh nghiệp để xác thực nhân viên sẽ không phù hợp ở chỗ chi nhiều tiền để giải quyết một rủi ro không quá nghiêm trọng. Thử nghĩ xem RSA SecurID khi dùng kèm với Active Directory để làm Windows logon authentication thì giải quyết được những rủi ro gì? Mình sẽ bàn kỹ về vấn đề này trong một post khác nếu có bạn nào muốn thảo luận.  

Mình nghĩ nếu đã muốn xác thực nhân viên, thì nên hướng đến xác thực việc sử dụng dữ liệu, bởi cuối cùng rồi thì dữ liệu của doanh nghiệp, chứ không phải tài khoản của người sử dụng, mới là thứ quý giá cần phải được bảo vệ. Thử nghĩ đến trường hợp nhân viên cố tình phá hoại, vốn luôn là rủi ro hàng đầu của mọi doanh nghiệp, thì chúng ta sẽ thấy giải pháp xác thực nhân viên lúc họ đăng nhập vào máy tính sẽ trở nên không còn có ý nghĩa.
Tương tự như các dịch vụ công, cái cần phải tập trung bảo vệ là các giao dịch tài chính, chứ không phải tài khoản của khách hàng.
 

Tương tự như các dịch vụ công, cái cần phải tập trung bảo vệ là các giao dịch tài chính, chứ không phải tài khoản của khách hàng.  

Gõ passcode lần thứ 2 có tác dụng ji? Em ko hiểu? Với 2 cách anh nói thì random đều đựa theo thời gian cả. Chỉ là 1 cái 1 khoảng tg nó random còn 1 cái khi người dùng cần thì nó random thôi.Còn client và AM chỉ xác thực 1 lần duy nhất. Vì vậy mốc tg là bên phía mỗi thiết bị. Vậy giã sử tg bên token chậm hơn bên server thì nhập passcode lần 2 để làm ji? Em ko hiểu.
 

Anh có thể giải thích giùm em chơ chế gửi node secret từ client tới server và cơ chế node secret được tạo ra bên server là ntn để nó phân biệt dc các agent của nó?
Thank anh. 

Mình đang gặp tình trạng tất cả các ổ đĩa trên HDD đều tự động share mỗi lần Restart.
Mình đã thử khắc phục bằng cách :
Start\run\Notepad\ok

Code:

Net share C$ /delete /y
Net share D$ /delete /y
Net share E$ /delete /y

Save lại *.bat >>> RUN
Sau đó mình kiểm tra lại thấy các ổ đĩa không còn bị share nữa.
Nhưng khi restart lại máy thì tình trạng trên vẫn tiếp diễn.
Giờ mình phải làm sao?
Rất mong được sự chỉ giáo của các bạn.
Mình rất cảm ơn !  

Cho em hỏi. Thuật toán tạo passcode dùng HOTP = HMAC-SHA1 đồng bộ giữa client và server dựa vào 2 yếu tố chính là shared secret và movingFactor.
MovingFactor là đồng bộ về thời gian, thời gian trên server là giờ hệ thống của server, còn thời gian trên client( mobile) là giờ hệ thống của client. Lỡ thời gian giữa 2 cái ko đồng bộ thì sao? Có cách nào giải quyết tốt vấn đề này? Hay phải tự đồng bộ thời gian giữa client và server?

Em đang làm đề tài về vấn đề này. Mong mấy anh giúp đỡ.
Thân. 

Shared secret là một key bí mật cần trao đổi giữa client và server ( em hiểu nôm na là thế).Vậy cho em hỏi cơ chế tạo ra secret là ntn? 

Có thể mô tả thế này:
- User vô web bình thường.
- Khi đăng nhập thì dùng username và passcode (= pass + pin code).

Vấn đề là mình không biết cách để nhúng giao diện của RSA vào giao diện đăng nhập của web!!!
Không biết mô tả thế bạn có rõ không  

Hi bạn,

Mình có thử tích hợp RSA vào web server (IIS), tuy nhiên mình chỉ làm được ở mức chứng thực qua RSA, sau đó mới vào web. Trong khi đó, yêu cầu thực tế là RSA phải nhúng vào ứng dụng web luôn (tương tự như các trang web ngân hàng). Mình đang lúng túng trong việc nhúng vào web, mình đã đọc tài liệu tích hợp web của RSA và được cung cấp 1 số hàm API để thực hiện, nhưng vẫn chưa làm đc.  

thangdiablo wrote:

Hiện mình cũng đang tích hợp RSA vào hệ thống nên sẽ rất vui nếu được trao đổi với những ai đã có kinh nghiệm trong việc này.
 

Hi bạn,

Mình cũng đang thực hiện tích hợp RSA 1 số phần như (VPN, logon domain, quản lý device, mobile, ứng dụng web) sử dụng cả hardware, software. Tuy nhiên phần nhúng RSA vào ứng dụng web (database Oracle) mình đang gặp khó khăn, bạn có thể chia sẻ 1 số tài liệu và kinh nghiệm cho mình không ? ( tất nhiên là không phải những tài liệu trên trang của rsa )

Thanks!

 

Hello Cuncon201,

Giải pháp VIP Access for Mobile của VeriSign về bản chất là giải pháp Mobile OTP đó. Đây là một giải pháp đang khá được ưa chuộng trên thế giới, mặc dù ở Việt Nam mình chưa thấy có doanh nghiệp nào áp dụng cả. Có lẽ mình đi chưa đủ nhiều .

Trên sourceforge có một project liên quan: hxxp://motp.sourceforge.net/. Bạn có thể tham khảo thêm.

Chúc may mắn.

 

Em đang làm đề tài về bảo mật token. Nhưng thay vì dùng USB token mỗi khách hàng phải mua 1 cái và đem theo bất tiện thì ta viết chương trình cho mobile. Em thấy trên mạng có VIP access for mobile của veriSign. Mấy anh nào đã từng nghiên cứu về cái này sharing cho em ít tài liệu.
Em cảm ơn!  

Tớ chúa ghét spam và từ khi bắt đầu dùng qmail làm MTA hồi năm 2000 cho đến nay, tớ đã khoái ứng dụng rblsmtpd (real time backlist smtp daemon) có trong qmail.

Ngày trước đoạn script run tớ thường dùng cho qmail-smtpd là:

exec /usr/local/bin/softlimit -m 2000000 \
/usr/local/bin/tcpserver -v -H -P -R -x /etc/tcp.smtp.cdb -c "$MAXSMTPD" \
-u "$QMAILDUID" -g "$NOFILESGID" 0 smtp /usr/local/bin/rblsmtpd -r relays.ordb.org -r relays.osirusoft.com /var/qmail/bin/qmail-smtpd >> /var/log/qmail/rblsmtpd.log 2>&1 

trong đó,
relays.ordb.org và relays.osirusoft.com là hai RBL servers. Chúng được rblsmtpd hỏi thăm mỗi khi có mail đi vào xem mail này có phải thuộc diện spam hay không trước khi tiếp nhận.

Thời gian gần đây, tớ thấy spams đi vào system càng lúc càng nhiều, bèn điều tra. Hóa ra hai cái servers trên chết tiệt hồi nào rồi nên chẳng còn real time blacklist gì ráo ) .

Tớ bèn google 1 phát và ra cái này:
http://www.email-policy.com/Spam-black-lists.htm

Sau khi duyệt xuyên qua cái danh sách và hí hoáy thử nghiệm, tớ thấy có 2 "anh chàng" ngon nhất và nhanh nhất đó là:
sbl-xbl.spamhaus.org và dnsbl.njabl.org. Thế là đoạn script run tớ dùng cho qmail-smtpd trở thành:

exec /usr/local/bin/softlimit -m 32000000 \
/usr/local/bin/tcpserver -v -H -R -l 0 -P -x /etc/tcp.smtp.cdb -c "$MAXSMTPD" \
-u "$QMAILDUID" -g "$NOFILESGID" 0 25 /usr/local/bin/rblsmtpd -b -r sbl-xbl.spamhaus.org -b -r dnsbl.njabl.org /var/qmail/bin/qmail-smtpd >> /var/log/qmail/rblsmtpd.log 2>&1 

Điểm khác biệt tất nhiên là 2 cái server mới ở trên. Tuy nhiên, điểm quan trọng là tớ dùng -b thêm vào. -b cho rblsmtpd có nghĩa là "Use a 553 error code for IP addresses listed in the RBL" (theo nguyên bản chú thích của Dan Bernstein). Bởi thế, một đoạn log mới của qmail's rblsmtpd.log cho thấy:

tcpserver: pid 27269 from 24.195.254.113
tcpserver: ok 27269 0xx.xxx.xxx.xxx:25 :24.195.254.113::1921
rblsmtpd: 24.195.254.113 pid 27269: 553 http://www.spamhaus.org/query/bl?ip=24.195.254.113
tcpserver: end 27269 status 0 

Đại khái tcpserver daemon báo rằng,
- process id 27268 nhận mail từ 24.195.254.113.

- sau đó, nó tiếp nhận (ok) ở dòng tiếp theo. xxx.xxx.xxx.xxx:25 là cổng smtp và IP của server của tớ, 24.195.254.113 và cổng 1921 là IP và cổng của máy (hoặc open relay server đó) gởi mail đến server tớ.

- dòng kế tiếp, rblsmtpd nhảy vào và query spamhaus.org xem IP 24.195.254.113 có bị blacklist hay không và cho biết kết quả 553 (SMTP Relay denied).

- dòng cuối cùng, tcpserver báo rằng process đó kết thúc, không có chuyện gì xảy ra. Điều này có nghĩa rằng, spam mail từ 24.195.254.113 không hề vào được hệ thống của tớ )


Ai dùng qmail nên thử xem thế nào? Ở đây tớ không bàn đến các phương pháp chống spam khác (như spamassasin... dùng fuzzy check, Bayesian filter... ) vì RBL là 1 dạng trong nhiều dạng chống.

Tớ nói thêm, những ai chưa dùng qmail thì bài viết này không có giá trị gì cả.

Thân mến. 

quanta wrote:

Bạn có thể cho biết đó là tài liệu gì không? 

à coi mấy tài liệu configure thiết bị switch 

Redundant data does not need to transit the WAN- reduces overall bandwidth usage
Tạm dịch là giảm thiểu việc dữ liệu trùng lặp đi xuyên qua mạng WAN qua đó sẽ giảm được băng thông nối tới chi nhánh.

 

Ồ, cái này thì đơn giản thôi: có một điều chắc chắn rằng intermediate systems không thể biết được TCP congestion control được sử dụng ở endpoints ra sao, thế nên việc tự ý retransmission sẽ dẫn đến packet duplications. Packet duplications sẽ dẫn đến duplicate acknowledgements. Nếu nhiều duplicate acknowledgements sẽ dẫn đến việc TCP thắt chặt sliding windows, và cuối cùng là dẫn đến giảm tốc độ truyền dữ liệu. Ngoài ra, packet duplications còn dẫn đến các vấn đề về pricing.

Trên thực tế thì không phải lúc nào cũng như vậy, và tùy vào môi trường lẫn configuration, nhưng không có nghĩa là nó không thể xảy ra.

Duy có một ngoại lệ của việc retransmission ở intermediate systems là trong Wireless LAN, do BER và FER là tương đối lớn. Tuy nhiên, việc retransmission này không có vấn đề là vì: thường không có vấn đề về pricing, retransmission diễn ra ở data link layer, retransmission diễn ra trong local loop nên không tạo ra nhiều ảnh hưởng đến network. 

@thangdiablo: việc IP address có bị thay đổi hay không đâu có phụ thuộc vào thiết bị của Cisco hay là công nghệ gì gì đó. Vì vậy mình nghĩ quanh đi quẩn lại vẫn là VPN thôi.
 

Còn về cái trò "Tự động lưu và phát lại gói tin của giao thức TCP bị mất trên đường truyền thay vì đợi source host gửi lại", mình cho rằng khá là mạo hiểm.
 

End-to-end argument là một trong những vấn đề cốt lõi của networking. Việc sử dụng đặc điểm trên đòi hỏi sự hiểu biết sâu sắc về network operation theo một cách khoa học (scientifically). Nếu không sẽ dẫn đến các hậu quả thảm hại. Mình không nghĩ là nhiều network admin hoặc engineer có khả năng này, nên việc Cisco đưa cái này vào mình cho là không phù hợp.  

Chào mọi người !

Vừa rồi cisco có một hội thảo "Tối ưu hóa chi phí công nghệ thông tin của các chi nhánh " . Trong cuộc hội thảo này cisco giới thiệu giải pháp WAAS. Giái pháp này theo giới thiệu thì nó có khả năng tối ưu hóa giao thức tcp/ip. Mình cũng chưa thât rõ vụ tối ưu này như thế nào ?

Một số cty cũng đi chào giải pháp cũng liên quan tới tối ưu hóa tcp/ip như A 10 Networks ... Khi mà đường truyền vietnam chưa có khả năng mở rộng thì có lẽ giải pháp này rất hợp với chung ta.

Xét về góc độ kỹ thuật thì tối ưu hóa giao thức tcp/ip xảy ra như thế nào? Hoạt động ra sao ? Mong mọi người chia sẽ ,thảo luận . Thân 

[mình cho rằng kể cả switch có hỗ trợ STP thì vẫn bị "ngu" như thường. Tuy nhiên, cũng chưa có result chống lưng nên đành để sau vậy.