Messages posted by "mfeng"

Hỏi về dùng chung cookie cho nhiều domain

mfeng — GMT

Bạn tìm hiểu thêm về federation identity & một số triển khai & chuẩn như SAML, OpenID, OAuth, WIF. Ngoài ra có thể tự thiết kế thử nghiệm 1 protocol đơn giản dùng cookies có hoạt động tương tự được.

Xin hướng dẫn dùng Soft Pecompact

mfeng — GMT

Bạn cần phải biết các khái niệm, kiến thức & kỹ thuật unpacking. Nên tìm kiếm trong box này trước khi hỏi, vd xem ở đây: /hvaonline/posts/list/23682.html

Revert 1 số chuỗi mã hoá

mfeng — GMT

Encode bằng Base64.

Recruitment: Senior Developers at Hanoi

mfeng — GMT

WISeKey SA http://www.wisekey.com WISeKey is a leading information security and identity management company, and provides specialized security technologies for data protection, and effective identification and authentication of people and objects, over physical infrastructures, networks and the internet to ensure secure communications and e-transactions, without compromising trust. Position

Senior Developer (ref code WK-SD01)

Job description

Reports to Project Manager. Provide knowledge and development expertise in the given application domain Assists to the Project Manager to create application architecture code mapping solution Implements application modules Conducts developers on group: controls and coordinates development activities of the group Maintains up-to-date project development documentation Is responsible for maximizing development results reusability: informs project Team Leader about useful solutions implemented by the team Participates in knowledge sharing meetings Implements designed by Development team shared libraries and development techniques Provides quality assurance measures such as regular code revisions within the development team to assure that all project team developers know and follow coding standards. Informs Project Manager about discovered issues and helps to address them.

Job Requirement

Candidate must possess at least Bachelor's/College Degree in Computer Science/Computer Engineering or equivalent. At least 3 year(s) of working experience in the related field is required for this position. Requires an understanding of software development processes and software quality assurance procedures in a Microsoft development environment and 3+ years of related work experience. Knowledge of software products utilizing various Microsoft Windows operating systems is strongly preferred. Experience with .Net, Desktop/Web applications, databases is required. Experience with test automation tools is a plus. Knowing PKI/Cryptography is a plus. Candidate must have good communication/writing skills in English.

General Information

Job Type: Full-Time Permanent Location: Ha Noi Salary: 600 - 1000 USD per month

Contact

Preferred language for received applications:English. The application should be sent to kblackma@wisekey.com before Feb 28th, 2010.

Dùng Cert từ verisgn trên nhiều Web Server chạy song song?

mfeng — GMT

Theo mình biết thì khi trình duyệt kết nối với một https webserver, mặc định các trình duyệt hiện nay (xem http://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol#Browser_Support) đều kiểm tra tình trạng của certificate đó xem đã bị revoked hay chưa thông qua 2 con đường: - OCSP: Nếu trong certificate có chỉ định giá trị CRL Distribution Points trong X509 Ext, trình duyệt sẽ sử dụng tham chiếu này để kiểm tra tự động; có thể thay đổi cấu hình này. - CRL: được cập nhật bằng tay. Nếu cert đã bị revoked mà web browser không thực hiện kiểm tra khi kết nối, coi như cert đó vẫn hợp lệ.

Tuyển: IT Manager cho công ty chứng khoán

mfeng — GMT

Nghe nói d/c pr0f đang làm việc ngon lắm mà, không biết có ý định sang CK cho đổi gió không :)

Tuyển: 10 System Engineers for IBM Hanoi & Ho Chi Minh

mfeng — GMT

Tớ nộp trưc tiếp ở HN á :). Kể ra không xin được số ĐT cũng là sơ xuất (cần rút kinh nghiệm!), vì 2 vòng trước, cứ đều đặn sau 1 tuần thì có thông báo cả bằng mail & phone, đến vòng thứ 3, sau khi kết thúc được hứa miệng rằng sẽ có thông báo kết quả sớm, nhưng mà đợi không thấy ;)) Tớ pvan đợt đầu tháng 7.

Tuyển: 10 System Engineers for IBM Hanoi & Ho Chi Minh

mfeng — GMT

quanta wrote:

mfeng wrote:

Đợt trc tớ đi pvan IBM về 1 vị trí tương tự như thế này, qua 1 vòng test + 2 vòng interview thì thấy mất tăm, không có notification gì thêm cả :D
Thế xong bạn có gọi điện (hoặc mail) lại hỏi bọn nó không?

Có chứ :). Mail không nhận được reply. Điện thoại không gọi được vì không biết số :D (do IBM gọi đến handphone bằng cách gì đó giấu được số).

Tuyển: 10 System Engineers for IBM Hanoi & Ho Chi Minh

mfeng — GMT

Đợt trc tớ đi pvan IBM về 1 vị trí tương tự như thế này, qua 1 vòng test + 2 vòng interview thì thấy mất tăm, không có notification gì thêm cả :D

0-day in Mozilla Firefox 3.5 - critical

mfeng — GMT

Một số phân tích kĩ thuật thêm về bug này: Lỗi này nằm tại file js3250.dll. Đoạn mã khai thác lỗi cho phép điều khiển giá trị eax và ecx tại đoạn lệnh sau Code:

0038695C            83E1 F8                    AND ECX,FFFFFFF8
0038695F            8B11                       MOV EDX,DWORD PTR DS:[ECX]
00386961            8B02                       MOV EAX,DWORD PTR DS:[EDX]  ; <-- EAX bị sửa đổi ở đây
00386963            83C3 FC                    ADD EBX,-4
00386966            53                         PUSH EBX
00386967            6A 00                      PUSH 0
00386969            51                         PUSH ECX
0038696A            8B48 20                    MOV ECX,DWORD PTR DS:[EAX+20] ; <-- Dùng kỹ thuật heap spray để chèn đoạn padding & shellcode vào vùng bộ nhớ eax + 20.
0038696D            57                         PUSH EDI
0038696E            FFD1                       CALL ECX         ; <-- Shellcode được gọi từ đây

0-day in Mozilla Firefox 3.5 - critical

mfeng — GMT

Theo http://www.us-cert.gov/current/index.html#mozilla_firefox_3_5_vulnerability, Javascript engine của FF 3.5 hiện có thể bị khai thác thực thi mã độc khi người sử dụng mở trang web có nhúng mã khai thác. Đoạn mã khai thác đã được phát tán rộng rãi trên internet. Giải pháp hiện tại: Tắt tính năng Javascript hoặc làm theo hướng dẫn của US-CERT tại http://www.us-cert.gov/reading_room/securing_browser/#Mozilla_Firefox. Bổ sung: Có hai biện pháp giải quyết tạm thời - Dùng addons NoScript của Firefox hoặc - Tắt chức năng JIT của Javascript: trong about:config, đặt [color="red"]javascript.options.jit.content= false[/color] Sẽ có FF 3.5.1 trong tháng này nhằm vá lỗi của javascript và http://blog.internetnews.com/skerner/2009/07/firefox-35-at-risk-from-0day-j.html của FF 3.5. --- Sửa đổi bổ sung phần giải pháp tạm thời

Cần Tools scan các ip dính virus conficker

mfeng — GMT

- Nmap có chạy được trên windows. - Nmap quét conficker dựa vào các cổng: 135, 139, 445.

Cracker Handbook 2008 vol1 Unpacking !!!

mfeng — GMT

Quái nhỉ, sao RE cứ gắn với đầu lâu xương chéo là sao?

Xin giúp đỡ, bị SYN Flood

mfeng — GMT

Bạn tham khảo về cách thức kiện toàn TCP/IP Stack để hạn chế SYN attack: http://www.securityfocus.com/infocus/1729 Do kết quả lệnh netstat không cho thấy các kết nối đang ở SYN_RECV nên chưa có kết luận được gì về nguồn tấn công.

Về một số vấn đề khi đọc TCP/IP

mfeng — GMT

Windows size liên quan tới khái niệm Congestion Control và Flow Control. Thông thường nếu mỗi một segment gửi đi xong mà sender mà chờ ACK từ receiver rồi mới gửi segment tiếp theo, thì throughput sẽ quá thấp so với bandwidth. Vì vậy mới cần giải pháp pipeline, mà Window size có thể coi là số lượng segment gửi đi liên tục theo pipeline trước khi nhận được ACK.

Re: [?] Quá nhiều socket TIME_WAIT

mfeng — GMT

TIME_WAIT là trạng thái cuối cùng của một kết nối tcp trước khi đóng kết nối chủ động (chủ động gửi FIN). Hiện tượng nhiều TIME_WAIT thực ra không phải lỗi của OS hay TCP/IP stack mà nguyên nhân thường bắt nguồn từ tốc độ mở socket mới quá nhanh so với tốc độ giải phóng socket: mỗi socket sẽ đợi ở tình trạng TIME_WAIT 1 khoảng thời gian là 2 *MSL (thông thường là 120s, trên CentOS là 60s). Để khắc phục vấn đề này có các hướng sau: - Điều chỉnh tcp/ip stack nhằm giảm thời gian time_out để đóng socket time_wait và tái sử dụng socket: như quanta và secmask đang làm. - Xem xét ở tầng app xem tại sao client sinh ra nhiều socket tới server tới vậy (thường là do lỗi lập trình). Ở đây là kết nối http, thử xem xét vấn đề về keep-alive để tiết kiệm số sockets xem sao. - Search google: có một số giải pháp ở tầng TCP hoặc HTTP cho phép chủ động đóng bớt TIME_WAIT (Client chủ động gửi RST; thêm method CLOSE ở giao thức HTTP), nhưng có vẻ là khó triển khai với trường hợp này.

Re: Các cách xác thực người dùng bằng mật khẩu

mfeng — GMT

Các tiêu chí của một giao thức xác thực cần có sẽ là: 1. Chống sniffer 2. Chống replay 3. Có trao đổi session key. 4. Mutual auth 5. Chống được dictionary-attack dựa trên sniff messages 6. Đảm bảo forward secrecy. 7. Chống được tình huống compromised verifier database (chứa các thông tin bên server để auth). Theo các tiêu chuẩn trên, tất cả các protocol đang bàn luận này đều không thỏa mãn, nhất là 3 điều kiện cuối cùng, được gọi là "Big-3" của auth. Điều kiện thứ 7 chính là vấn đề mrro nói làm sao để cài đặt giao thức không dùng plaintext-equivalent password. Ít ra hiện giờ có một giao thức thỏa mãn 7 điều kiện trên, được viết thành RFC 2945. Các bạn thử tìm hiểu và phân tích xem :).

Re: Finding DHCP in Lan Network !!!!

mfeng — GMT

Sau khi kết nối vào wifi (dùng đúng key), thử "lắng nghe" trên mạng đó coi nghe được thông tin bổ ích gì không? :)

Re: Các cách xác thực người dùng bằng mật khẩu

mfeng — GMT

Ờ, lâu không coi lại, giờ xem protocol 5 thế nào nhé :) Code:

Protocol 5:
 
 1. Alice tạo cặp khóa Public Key  (PR,PU) . Alice gửi M1=E(pw, PU) tới Bob.
 2. Bob giải mã M1. Tạo M2= E(PU,sk||nonce) gửi lại Alice
 3. Alice gửi E(sk,nonce) cho Bob.

Mục tiêu của giao thức authentication này diễn ra giữa user và server. Ở đây Alice là user, Bob là server có phải không ?. Vì có trước giả thiết là: - Hai đầu cuối (usr & server) là tin cậy, không có khả năng bị compromised. - Đường truyền bị theo dõi & có khả năng bị replay. Nêu mọi thảo luận sẽ nằm ở an toàn của thông tin trao đổi trên đường truyền chứ không phải thông tin cần lưu trữ, mặc dù điều này khá quan trọng khi cài đặt một giao thức xác thực. Câu hỏi: - Step2: Làm sao Bob giải mã được M1 khi không biết thông điệp M1 được gửi từ Alice1 hay Alice2 ? - Giao thức trên sinh Pub/Priv key, rồi dùng pre-shared password để gửi Pubkey, sau đó dùng lại PubKey để trao đổi session key. Cách làm trên ưu điểm hơn gì so với dùng luôn password để trao đổi session key?. Và vấn đề gì sẽ xảy ra khi mỗi lần gửi đi các PubKey đều dùng lại một key để mã hóa ? Nhìn chung protocol 5 có vẻ giống một key exchange protocol hơn là một authentication protocol.

Starghost wrote:

Protocol này hay ở chỗ entropy của các messages không phụ thuộc vào password. Thế nên không quan trọng password dài ngắn ra sao, việc bruteforce password là không thể.

Protocol này có sử dụng password làm key để mã hóa PubKey, thức là có phụ thuộc vào password chứ nhỉ :). Nếu xét về khả năng bruteforce M1 thì tại sao lại không có ?

Re: Ngâm FTP Protocol từ đâu?

mfeng — GMT

Trước hết: - Đọc TCP/IP: hiểu rõ TCP, IP là cái gì, protocol là cái gì. - Học lập trình hệ thống mức cơ bản: read/write files, multi-threading... - Học lập trình socket: tạo server socket như thế nào, client socket như thế nào, cách gửi thông điệp giữa hai máy tính thông qua socket... - Đọc giao thức FTP và triển khai: ban đầu là http://www.w3.org/Protocols/rfc959/. Theo mức độ yêu cầu của đề tài, bạn chỉ cần cài đặt một phần tối thiểu giao thức này là được.